The list of potential stable timestamp candidates is maintained in memory, in
ReplicationCoordinatorImpl::_stableTimestampCandidates. It will need to be cleared after recovering to a timestamp or when starting a new initial sync. During rollback, after recovering to the stable timestamp, the replication system will apply oplog entries between the stable timestamp and the common point. Before this oplog application process, we should clear the list of all timestamps except the stable timestamp. The oplog entries between the stable timestamp and the common point may get applied differently than they were originally, so we need to clear the timestamp list before doing this to avoid leaving timestamp candidates in the list that might no longer fall at a consistent point.

Note on the 'rollbackViaRefetch' algorithm in 3.6:

For 3.6, where we still use the "rollbackBackViaRefetch" algorithm, we will need to do the following to make sure we are never setting the stable timestamp to a timestamp at an inconsistent state:

1. Upon entering ROLLBACK, set a flag, dataConsistent=false
2. Upon reaching minValid, in tryToGoLiveAsASecondary in sync_tail.cpp, set dataConsistent=true, since reaching the minValid optime implies that the database state is now consistent.
3. We should never add an optime to the set of stable optime candidates in ReplicationCoordinator if dataConsistent=false
4. Upon leaving ROLLBACK, clear the list of stable optime candidates that are past the current stable optime.