renameCollection is not supposed to be allowed to run on sharded collections.

However, today shardCollection and renameCollection can run concurrently, and therefore race.

So, we can end up in a situation where the UUID in a config.collections entry (propagated from the primary shard through shardCollection) differs from the UUID on the primary shard (after renameCollection).

In this case, it is as if the collection has been dropped and recreated as unsharded, but the entry for the old sharded collection doesn't get deleted from config.collections.