The OplogVisibilityManager (OVM) currently exists a member of LocalOplogInfo, which is a decoration on the ServiceContext. As a result, the OVM shares the same lifetime as the ServiceContext, meaning it remains active for the entire lifespan of a node without ever being deleted or initialized. However, the visibility timestamp can be reset in two ways:

1. The timestamp can be set to the "last applied" timestamp by LocalOplogInfo's setRecordStore() function (which calls OplogVisibilityManager's reInit()). This happens whenever the oplog pointer is set, which can happen multiple times during the lifetime of the node. This calls into the WiredTigerOplogManager's (WTOM) storeOplogVisibilityTimestamp() function.
2. The timestamp can be set to a specific timestamp specified by the caller (eg. in _truncateAfter() during replication rollback) through OplogVisibilityManager's setOplogVisibilityTimestamp(). This calls into the WiredTigerOplogManager's (WTOM) swapOplogVisibilityTimestamp() function.

We should investigate whether it is possible to add the following invariants in OVM's setOplogVisibilityTimestamp() / WTOM's swapOplogVisibilityTimestamp() to enforce that the visibility timestamp can only progress forward:

auto prevVisibilityTimestamp = _oplogVisibilityTimestamp.swap(visibilityTimestamp);
invariant(prevVisibilityTimestamp <= visibilityTimestamp);
return oldVisibilityTimestamp;

In order to add this safely, we need to ensure that the timestamp is reliable resent to the "last applied" through reinit() before invoking the latter force-setting logic. We'll likely only be able to validate this behavior after transitioning existing calls from WiredTigerOplogManager's setOplogReadTimestamp() to OVM's setOplogVisibilityTimestamp().