Previously, refineCollectionShardKey was implemented in a way where even after it's execution there could be some shards that were not aware of the change, so, during the work of SERVER-71690 (which added a filtering metadata check hook), the filtering metadata check had to be disabled. However,
SERVER-76486 changed the refineCollectionShardKey implementation to a model where the collection version changes are performed under a critical section in a stable cluster (as in, without migrations running) for all the shards with collection data, so, it is now safe to do those checks. An example of this is ddl_ops_reported_on_current_op_command.js.

The purpose of this ticket is to search for all the tests that had the check disabled because of the previous behavior of refineCollectionShardKey, and re-enable them.