Not bumping the collection version is a problem for scenarios like:

1. Creation of Collection A
2. Creation of Collection B
3. Rename of A to B, dropping target collection.

Assuming that a router saw A and B before the rename, if this router tries to refresh its routing information about B after the rename, this refresh will hang forever.

The underlying problem is that since we didn't bump the collection version, the router thinks that the routing info it has about B is more recent than the one it gets from the config server.

Solution:

We have to bump the collection version. The Collection Version of B after the rename should be newer than the one we had for B before the rename.

1. If we take the conservative approach, this would imply modifying all entries in config.chunks for this collection + its entry on config.collections. Doing that should be enough and it will behave similarly to what we do in refineShardKey. As a drawback we will have to update all chunks associated to the Collection which is something we tried to avoid as much as possible: that's why we replaced the namespaces by uuids, to avoid having to update all chunks.
2. The other approach tries to avoid having to update all docs associated to the collection on config.chunks. Since the replacement of NSS by UUID on config.chunks, we believe that there is no reason to have the epoch and the timestamp on config.chunks. Thus, if we manage to get rid of those, the rename will only have to update config.collections. In order to support backward/forward compatibility we will have to do some minor modifications to the setFCV cmd.

We are going to implement the second option. The goal of this ticket is to add a new configserver command that should be called when we commit the rename operation. This new command should do the work being done + bumping the version (i.e. changing the timestamp and the epoch of the collection). We should also take the _kChunkOpLock lock, so we disallow weirds interleavings of rename collections with merge/split chunks.