While working on SERVER-122957 we discovered that we hadn't considered an edge case of rename. Namely, that renames across databases end up requiring a new UUID on the collection.

While investigating this limitation it was discovered that this behaviour predates the usage of WiredTiger and is a legacy behaviour that has been maintained throughout versions to this date. In fact, Github doesn't even allow us to go that far back in time to see the original reason since it caps out at 2015.

However, this is not really necessary today since changes to both shard-local and the global sharding catalog can be done atomically for both untracked and tracked collections.

That is, the only currently valid limitation for rename is renames of unsharded and untracked collections as they have to occur within a single shard (the dbPrimary). All other limitations are unnecessary and impose cognitive overhead when having to make changes to the codebase. As a result, we don't need to transform renames across databases into a drop+create.