`flushRoutingTableCacheUpdates` and `flushDatabaseCacheUpdates` commands aim to refresh the filtering metadata, which means, triggering a refresh of the catalog cache to install potentially new metadata in the CollectionShardingRuntime or DatabaseShardingState.

These commands are used internally in the code with only that intention. An example of the usage could be at the end of a DDL operation when the DB primary shard wants to warm up the filtering metatada as a best-effort refresh of the participants of the DDL.

On the other hand, testing is abusing the fact that the CatalogCache is refreshed, which means routing information. This is no longer true after SERVER-95393 [Dedicate a catalog cache and loader to the shard role], as the filtering metadata has its own cache. To not break many tests that rely on that assumption, SERVER-95393 committed a workaround that the flushCacheUpdates commands will also refresh the dedicated CatalogCache for routing.

This ticket tracks the work to remove that and update the necessary tests to not rely on this command to warm up routing information.