SERVER-103711 introduced a new tassert to verify that the filtering metadata protecting a DatabaseShardingRuntime instance can only be cleared after acquiring and promoting the related CriticalSection to the Commit phase (so that the cached DB version gets only refreshed when actually stale).

This logic started to conflict with the behavior of movePrimary(dbName) operations being aborted, which could request a clear of the filtering metadata while the CriticalSection of dbName was still in Catchup phase.

SERVER-110225 tried to solve the problem by skipping the clearFilteringMetadata step on the coordinator side while aborting: this allowed to preserve the original logic of the tassert, but proved to be a partial fix (as it did not take into account the behavior of the recipient, as well as secondary nodes, which are insensitive to the changes).

After re-evaluating the situation, there is consensus around relaxing the tassert and allow movePrimary to (unnecessarily) clear filtering metadata when aborted.