Currently we advance our oldest timestamp to lastApplied whenever we are in STARTUP2 state. This was originally intended to relieve cache pressure during initial sync oplog application, as described in SERVER-32226. The current logic, however, is not strictly scoped to initial sync oplog application, since we pass through STARTUP2 whenever we start up and go through recovery on our way to SECONDARY. This means that, after a normal startup recovery procedure, we will set our lastApplied and oldest timestamp to the top of the oplog when we load our optimes from disk here. This can lead to a case where we become SECONDARY and our oldest timestamp is ahead of our initialDataTimestamp before we have set a stable timestamp. Due to the changes in SERVER-47844, this can cause an issue where we try to set our first stable timestamp behind the oldest timestamp, since we use the initialDataTimestamp as a barrier behind which we will not set the stable timestamp. To avoid this problem, we should move this logic into the setMyLastOpTime callback which is the specific location where we advance lastApplied during initial sync oplog application.