When movePrimary forces the same collection UUID as in the source, it is possible to end up with a Collection instance which uses an incorrect ident / RecordStore pointer.

This is possible when:

• movePrimary a collection from shard0 to shard1.
• movePrimary the same collection from shard1 back to shard0.
• A PIT read on shard0 establishes a consistent collection at a point in time before the collection was first moved away.

(Note: Even if UUID is forced during collection creation, the underlaying ident / WT table will be new).

The logic for creating a compatible collection involves using the SharedState of the latest collection instance to initialise a new PIT collection instance (link), but fetching of the latest instance only relies on the UUID, which remains the same across movePrimaries. The SharedState contains the pointer to the RecordStore, thus we end up in a situation where the Collection instance is pointing to an incorrect ident.

Index idents will be correct, as those take a separate path outside the shared state. An specific example of this is dbHash returning corruption errors due to not finding the collection entry corresponding to an index entry, when in fact it is the collection catalog which is incorrect.

We should fix the logic instantiating PIT compatible Collection instances.