We need to verify that an unfinished 4.0-style two phase drop (by-renaming way) could be handled nicely on startup of 4.2 binary.

If an 4.0-style two phase drop is unfinished on the shutdown of 4.0 binary, it means the first phase (renaming the collection to db.system.drop.xxxx) is completed (committed but not checkpointed yet - there is no db.system.drop.xxx on disk) but the second phase (the drop of db.system.drop.xxx) is not. And a "dropCollection" oplog entry is written (committed and persistent on disk in the form of WT journal).

On the startup of 4.2 binary, MongoDB will start with the last checkpoint which has the original collection and replay the oplog entries including that "dropCollection". The collection will be dropped with 4.2-style (new way) two phase drop mechanism. There will be no dangling "db.system.drop.xxxx" after startup and 4.2 binary does not need to do anything related to the 4.0-style two phase drop in this case.

This applies to both primary and secondary nodes. This ticket is to write a upgrade test to verify the theory.