As part of SERVER-130600, we temporarily introduced logic that skips the oplog scan portions of initializeMetadata and replicated fast count manager startup if there is no persisted valid-as-of timestamp and we have more oplog to scan than we reasonably think we can catch up on. This was done to prevent blocking advancing the valid-as-of timestamp and to prevent blocking startup. However, the downside of this is that fast size and count are likely to be incorrect when this happens.

The goal of this ticket is to find a longer-term solution to this.

We should also look into updating oplog_lag_secs even if we do not successfully complete our first flush - otherwise, even if the initial flush is taking a long time, the metric would remain 0.