checkMetadataConsistency does not perform any writes during its execution. This means it can run certain validations even in a split-brain scenario. This is already accounted for by not reporting false positives when the node is a secondary by the time execution completes.

However, with authoritative DB shards, accessing the DSS is more strict: we cannot access its contents if the critical section is held by another thread.

Currently, checkMetadataConsistency violates this protocol because it may run on a secondary node that believes it is primary, and it sends the participant command to the actual primary. This results in accessing the DSS while a DB DDL operation is holding the critical section.