If the DatabaseShardingState, which stores a shard's in-memory cached database version, remains a decoration on Database, then it is not possible to check a client's database version on a shard that does not actually have the database.
This is a problem because a database can be dropped and recreated on another shard, and a stale mongos can still target the old shard, which will not perform the version check and so not tell the stale mongos to refresh and reroute.
Let's make DatabaseShardingState more similar to CollectionShardingState by:
1) creating a standalone DatabaseShardingStateMap that will hold all the DatabaseShardingStates and be a decoration on ServiceContext (analogous to the CollectionShardingStateMap)
2) making _configsvrDropDatabase send _flushDatabaseCacheUpdates to all shards (analogous to _configsvrDropCollection sending setShardVersion to all shards)