As designed in WRITING-7769, when upgrading FCV in a sharded cluster, the configsvr will invoke the setFCV command twice on shardsvrs: phase-1 and phase-2.

If a stale retry of a setFCV(phase-1) happened after a shard has already entered phase-2, the shard would be left in the temporary (upgrading/downgrading) state (it would enter phase-1 again). This wasn't an issue when FCV was a monolithic command, but since now it will consist of two different command invocations to the shards, we need to account for it.

The proposed solution is to add a 'timestamp' field to the FeatureCompatibilityVersionDocument. This field will be selected and persisted by the ConfigSvr each time a setFCV sequence starts. When the ConfigSvr invokes setFCV on the shards, it will be passed as part of the command parameters and the shards will use it to decide whether they should initiate each phase by performing a compare-and-swap write checking that the timestamp they receive is newer.