cache config

We need to implement a cache for configs, since relevant data will need to be used per request e.g. oidc settings. We wouldn’t want to make a DB call every time to get those configs. This means we need to implement it in a distributed manner as well i.e. if configs gets updated, all members in the cluster will need to update their local cache and the cache will need to be locked with a Mutex (not RWMutex). Furthermore, we also need to consider the possibility of cache update failing on a member, we would need to revert the changes to configs for all members.

This should be done for both manager and member specific configs.

Start by locating the code paths that read and update manager-specific and member-specific configs, then trace how config changes are propagated across cluster members. Define the cache, Mutex locking, update-failure handling, and rollback behavior before implementing. Done means repeated requests avoid unnecessary database calls and every member stays consistent after successful or failed updates.

Written by the indexing model from the issue text.