In BF-9590, we could enter dropCollection() with kMajorityCommitted ReadSource since it's set previously by another command which used the same RecoveryUnit. Then, we read the on-disk index catalog with majorityCommitted timestamp and compare it with the in-memory one. If an index creation was just done after the majority committed point, the in-memory and the on-disk index catalog did not match.

I think we should assert that DropCollection() is performed with kUnset/kNoTimestamp ReadSource, or at least be aware that DropCollection() can be performed with other ReadSources. It would be useful to prevent bugs that arise from misusing the storage layer that are difficult and racy to diagnose.

Potential fixes:
1. Use AutoGetCollectionForRead in dropCollection() to get the collection. AutoGetCollectionForRead has the check for conflicting catalog changes. If the ReadSource is set to a majority timestamp which is less than MinVisibleSnapshotTimestamp, AutoGetCollectionForRead throws an exception and dropCollection() can retry.
2. Put an invariant "opCtx->RecoveryUnit()->getTimestampReadSource() == kUnset" in dropCollection.