Original title: The MigrationDestinationManager can send a remote listIndexes cmd by collection UUID w/ SV such that the receiving node's OSS sets shardVersion for an invalid namespace string

The MigrationDestinationManager can send a listIndexes command by collection uuid w/ shardVersion, such that a receiving node parses the command request and sets the shardVersion on the OperationShardingState under the invalid namespace "db.". Then later CollectionShardingState::checkShardVersionOrThrow doesn't find the shardVersion set under "db.", because the CollectionShardingState's internal _nss is a valid nss (converted from the UUID), and no shardVersion check occurs.

It doesn't appear that resharding is broken because of this, re: max.hirschhorn's observation:

I suspect the shardVersion isn't that important to resharding for the listIndexes command because the sharding metadata has already been frozen by this point so the MinKey-chunk owning shard and we always force the current primary recipient shard to refresh before sending the listIndexes command - https://github.com/mongodb/mongo/blob/f3eddd41dce816d1995393d5536f3afba5f8563f/src/mongo/db/s/resharding/resharding_recipient_service_external_state.cpp#L60-L62

However, it appears that the shard version protocol doesn't currently work with commands using collection UUID instead of namespace string, and there is an active use case, technically. The OperationShardingState should probably do a NamespaceString::isValid check on a provided NamespaceString before entering a nss-SV pair into its internal nss-SV map.

This is also a potentially dangerous behavior because if a read command does send UUID w/ SV then query is going to use collection shard state filtering for its read without verifying the SV matches the request (since the request is quietly setting up SV on OSS incorrectly). We're doing this benignly for the listIndexes scenario described above.