(Subtask to achieve SERVER-84243 - Dedicate a catalog cache and loader to the shard role. For more information refer to this document)

Today, the shard refreshes the filtering metadata using the CatalogCache and its ShardServerCatalogCacheLoader, which is shared by the routing information refresh.

If a primary directly calls the methods of the CatalogCache, which should only be used when consulting routing information, it can affect the filtering metadata knowledge of the shard. Once the shard role has its own CatalogCache and CatalogCacheLoader, we will no longer have this dependency between caches - they will be independent - and some DDL may be making wrong assumptions.

The identified patterns are as follow:

• Refresh of the filtering metadata + waitForCollectionFlush.
  • This is a correct pattern, as the refresh is done via the filtering metadata layer.

• Refresh of the catalog cache + waitForCollectionFlush.
  • This is not broken today, because refreshing the catalog cache via the routing layer in a shard implies using the ShardServerCatalogCacheLoader, which will fill the config.cache.* collections. Once the refresh of the routing catalog cache is done via the ConfigServerCatalogCacheLoader, this pattern will be broken. Instead, those operations need to refresh the filtering metadata and then wait for the collection to be flushed.

• Refresh of the catalog cache in DDLs without waitForCollectionFlush.
  • We need to investigate if there are some DDLs that should be refreshing the filtering metadata and then waiting for the collection to be flushed, and instead they are only refreshing the catalog cache.

The goal of this task is to identify all the usages and fix them within this work.