With actual implementation of the shard key index inconsistency checks, if we are running the checkMetadataConsistency cmd in a recipient shard part of a migration, and that shard had no chunks about the collection being migrated (chunk version <0,0>), we will skip the checks.

https://github.com/10gen/mongo/blob/be31cc047874ed3c6854534bf419021655535034/src/mongo/db/s/metadata_consistency_util.cpp#L230-L249

This is done because there is a space where the collection is registered on the recipient's shard but it has no indexes yet.

https://github.com/10gen/mongo/blob/be31cc047874ed3c6854534bf419021655535034/src/mongo/db/s/migration_destination_manager.cpp#L1079 

The goal of this ticket is to investigate if there is a more optimized way of checking shard key indexes when there are migrations.

A possible optimistic approach was to first check if the shard key index exists, and if not check if there is a migration running.