We currently re-calculate the oplog visibility point when every transaction commit, but this is wasteful when nobody is waiting for visibility. Notably, during oplog fetching.

We can make this more efficient by only recalculating the visibility point when there is a caller actively waiting for visibility to advance.

This is complicated by the fact that the notification mechanism of the CappedInsertNotifier is used for both oplog visibility and replication metatadata propagation, so we need to rewrite the component as follows:

• Have oplog waiters wait for either visibility to advance or a forced wakeup to send an empty getMore. This should go through a component other than the CappedInsertNotifier for reasons stated below.
• Only recalculate visibility and notify if there are active waiters. This requires that we can determine if there are active waiters in a critical section. Currently, that is not possible because the CappedInsertNotifier has a different mutex and critical section.
• Allow replication to forcefully wake up waiters without updating visibility, in order for replication to propagate commit point metadata via empty getMore batches
• Have waiters recalculate visibility on-demand if they become the first waiter