The solution for SERVER-126254 advances the durable optime so that durableOpTime would not get stuck behind lastWritten while the node is locked. That fix rested on an assumption that turned out to be incorrect:

On startup recovery we always truncate the oplog at the oplog truncate after point, regardless of whether an individual write was journaled or not. Because the durable optime was advanced without the corresponding oplog truncate after point update, a node can acknowledge as durable an entry that will be truncated away on restart.

We have decided to revert SERVER-126254. That revert reopens the original problem: with the featureFlagReplicatedFastCount variant, fsyncLock can leave durableOpTime stuck behind lastWritten and fsync.js fails (BF-45325)

This is safe from a product coverage standpoint today:

• fsyncLock is not enabled on DSC.
• Replicated fast count is not enabled on ASC, and is not expected to be for a long time.

So there is no configuration currently shipping where both features are active at the same time. fsync.js keeps running everywhere else, so fsyncLock coverage on the default configuration is unchanged.