As part of PM-2384, we introduced two ways of creating the chunks cache on shards: based on the name of the original collection or based on the UUID of that collection.  An invariant of that project, which we don't explicitly check although we might want to do it, is that only one chunks cache exists at the same time. However, this is not always true (from BF-22521):

1. P1(Primary): it starts a refresh of a certain nss. Despite the fact that in the config server we find that this collection supports long names and the previous info we had about it didn't, we don't actually rename the chunks cache because the epochs are different (which makes a lot of sense).
2. P1(Primary): The background thread starts removing the entry on config.cache.collection and the config.cache.chunks.nss. A bit after we dropped the chunks cache this node stepsdown. The drop of the chunks cache is rollbacked but not the deletion of the entry on config.cache.collections because it was majority committed.
3. P2 (New primary): it starts a refresh of the same nss. It doesn't see anything about that name on config.cache.collections since the previous operation was majority committed. maxLoaderVersion is UNSHARDED.
4. P2 (New primary): it finds valid data on the config server. It creates a task that it is executed by the background thread.
5. P2 (New primary): the background thread is going to persist the valid info we got from the config server. Since maxLoaderVersion is UNSHARDED we believe that we don't have information about the previous collection so we don't drop config.cache.chunks.nss. A few statements later we create config.cache.chunks.uuid, having two chunk caches for the same name.

A few questions we have to solve:

• Would it be enough to drop the target collection here?
• Can we avoid leaving garbage?