Right now the stable checkpoint can reflect data at a timestamp after the checkpointTimestamp/lastStableCheckpointTimestamp. This means we must relax idempotency constraints at startup and have no idea what time the data actually reflects. It also means that we cannot set the initial data timestamp until replication recovery ends which limits the time where snapshot reads can occur and makes replication recovery a slightly longer process. We should make sure that whichever mechanism we use to keep track of the stable timestamp at startup is correct.

Before 4.0 is released, we should ensure that whichever method we use, if not correct, has a path to correctness here to limit upgrade downgrade concerns in the future.