Consider the following scenario (kudos shane.harvey and MongoOrchestration):

• Bring up a 4.0 binary on 3.6 data files (or, start a new sharded cluster which starts out in FCV 3.6)
• Take a first stable checkpoint
• Upgrade to FCV 4.0
• Do some writes
• Crash

Running `./mongod --repair` will not run replication recovery, leaving the FCV value in 3.6. When the node shuts down, it will downgrade to 3.6. This will take an unstable checkpoint, unsetting the WT recovery timestamp. However, none of the "Do some writes" (nor the FCV upgrade) will persist in the checkpoint. Restarting a 4.0 binary will believe the data is consistent at the top of oplog, when it actually needs to recover from the now deleted WT recover timestamp.

A 4.0 binary must not downgrade if replication recovery was not run.