Instead of allowing entries to create the config.shard.databases collections dynamically when inserting for first time, we should evaluate the feasibility of initializing this collections at startup.

This would enforce a stricter contract ensuring that these namespaces remain unchanged unless explicitly modified during maintenance mode.

Furthermore, when we are executing this code, we are already in an OpObserver, which means we are not in a clean context. Creating a collection in this context has the possibility of causing deadlocks (or at least we have to think hard why there are no deadlocks) and inheriting settings from an already running operation. Basically, all the problems that stem from doing database things in the OpObservers.