Ideally, refreshing a cached database entry would only involve reading from "config.databases".

But for historical reasons, refreshing a database also reloads the list of the database's sharded collections (throwing out their cached routing info) and marks them as needsRefresh.

Unfortunately, we can't stop loading the sharded collections on database refresh, because pending SERVER-32198, shards treat a missing cache entry to mean "unsharded."

If we did, if a test uses a stale mongos against a shard whose in-memory cache has been reset, the stale mongos will refresh for the database but not for the collection -> mongos will send shardVersion UNSHARDED -> the shard will also believe the collection is unsharded -> the test fails because some documents were not found, count is wrong, etc.

Specifically, these suites would fail:

• read_only_sharded - because it restarts all shards + mongos, clearing their in-memory caches
• concurrency_sharded_causal_consistency - because it does reads through a stale mongos against secondaries that have never loaded their cache into memory
• concurrency_sharded_with_stepdowns - because it does reads through a stale mongos, and after a shard stepdown, the secondary that steps up has never loaded its cache into memory

Once SERVER-32198 is in, we should stop loading the sharded collections on database refresh.