When the catalog shard feature flag is enabled, a config server will start up with shard components. If the config server is in the latest FCV, it will insert a shardIdentity document locally and consider itself a shard always. To support downgrading to a previous binary, we'll need to remove the shardIdentity document on FCV downgrade, unset ShardingState::enabled(), and ensure the config server can still function properly as a dedicated config server. We'll need to support the inverse when upgrading FCV, ie insert a shardIdentity document and verify the config server functions in both dedicated and catalog shard mode.

Some specific problems to handle:

• The config server will use a ShardServerCatalogCacheLoader (SSCCL) in all FCVs and we should add logic to the SSCCL to become a pure passthrough to its underlying ConfigServerCatalogCacheLoader when FCV is not fully upgraded. This will require gating its behavior on FCV and joining any in progress tasks during FCV upgrade and downgrade.
• Shards don't allow deleting the shardIdentity document, which we'll need to relax for this case.
• ShardingState doesn't support unsetting ShardingState::enabled() currently