To implement consistency checks that metadata is consistent with FCV in validate, checkMetadataConsistency, etc. we'd like to use the following optimistic pattern:

1. Read the FCV document
2. If we are upgrading or downgrading, report no inconsistency (a concurrent upgrade/downgrade is happening).
3. Run the inconsistency check
4. Re-read the FCV document, if it has changed, report no inconsistency (a concurrent upgrade/downgrade happened).
5. Return the result of the inconsistency check.

On replica sets, there's however an ABA problem risk that between (1) and (4) a full upgrade+downgrade cycle happened and we read the same FCV document.

On sharded clusters this isn't a problem because we associate and persist a changeTimestamp associated to each FCV transition.

This ticket is to generalize the changeTimestamp to also be used in replica sets to enable this use case (plus reduce the amount of edge cases).