After SERVER-54908, we will also need to change 4.4 to prevent a 4.4 binary from starting up if the secondaryDelaySecs field is present. This would only occur during a manual downgrade (i.e. not using Atlas):
1. Start up shard server processes on MDB 4.9 / FCV 4.4.
2. rs.init() with secondaryDelaySecs.
3. Downgrade shard binary to MDB 4.4 / FCV 4.4 (MDB won't automatically change existing secondaryDelaySecs fields to slaveDelay since that occurs only when downgrading the FCV).
4. User now has a 4.4 binary that will silently ignore the secondaryDelaySecs field entirely.

By adding an error during startup in 4.4, the user will know that they have to change the field back to slaveDelay in order for MDB to properly use the delay field. We should document this behavior.

EDIT:
Since 4.4 will already fail to parse an invalid config and not startup, this ticket will just add a test for 5.0.