We check here that the shardVersion we began the migration with is still the shardVersion. This seems like an unnecessary check now, since shards no longer hold distributed locks.

We're running into a race condition when a shard is the recipient of a chunk and then the donor of a chunk in quick succession. This is the scenario:

• There a migration from shard Y to shard X.
• We release destination shard X before the donor shard Y commits the migration to the config server.
• Shard X starts acting as a donor shard in a new migration, still before shard Y commits the previous migration.
• Donor shard X reloads the chunk metadata at the start of the new migration, setting the MigrationSourceManager::_collectionMetadata with that newly loaded chunk metadata.
• Shard Y finally finishes the commit.
• Shard X attempts to enter the critical section, checks MigrationSourceManager::_collectionMetadata's shardVersion still matches the shard's current chunk metadata, sees that they're different and fails.