When a collection is being dropped using old-style two phase drops (system.drop.* introduced in 3.6), there is a small window in which we may be able to drop indexes on the collection. using its drop-pending namespace. This produces an sequence of operations that may be problematic for a secondary to apply. This is not a common scenario in production because it requires the user to be able to derive the drop-pending namespace of the dropped collection, either from the logs or the oplog, and run the dropIndexes command on the primary before it is permanently removed by the DropPendingCollectionReaper.

------ OLD DESCRIPTION BELOW ------

Old title:  Old-style two-phase drops replicate 'dropIndexes' operations after collection 'drop'

Old-style two-phase drops write an initial 'drop' oplog entry to rename the collection to a drop-pending namespace. The DropPendingCollectionReaper asynchronously drops the collection, which also drops the indexes and replicates the "dropIndexes" oplog entries.

As a result, the "drop" oplog entry replicates before the "dropIndexes" entry. If a secondary has already applied the "drop" and performed the second drop phase, when it applies the "dropIndexes" operation it will encounter a NamespaceNotFound error in replication, which leads to a crash.