The current visibility timestamp is accessed in the following situations outside of waiting for visibility to progress via a waitForTimestamp[...] method:

1. WiredTigerRecoveryUnit uses getOplogReadTimestamp to set its internal read timestamp when requested.
2. WiredTigerServerStatus also invokes getOplogReadTimestamp to decorate a BSON section with the current value to be logged.

Currently, both of these uses refer to the WiredTigerOplogManager (WTOM) to access the read timestamp. Ideally, the WTOM would be removed as part of this project, but instead we opt for a smaller scoped alternative:
The WTOM has zero active internals when the project’s feature flag is enabled.
The background thread and member variables are not used under the feature flag, and are deleted from the codebase when we remove the feature flag.
With the feature flag enabled, the OplogVisibilityManager (OVM) pushes visibility updates into the WTOM every time its visibility changes.

Note that this requires a link-time dependency from the LocalOplogInfo class to the WiredTigerOplogManager. It is possible to implement this with a “pull” design, where the WTOM pulls timestamps from the OVM when necessary. However, that would reverse the dependency order and result in another layering violation (a lower level library depending on a higher level one) so we opt to say with the “push” design and allow the OVM to drive visibility updates eagerly. We will implement this in this ticket