TLDR; we need to investigate whether we have RecoveryUnit::setTimestampReadSource() calls outside of the AutoGet* helpers in lock-free read operation codepaths. These could invariant if timed with a repl state change.

--------------------------------------------------------------------
Context:

I found a bug described in SERVER-54889 wherein the AutoGetCollectionForReadLockFree is misbehaving regarding the use of RecoveryUnit::setTimestampReadSource() establishing a read source.

---------------------------------------------------------------------
Example concern:

Perusing the codebase, I see that the getMore cmd can call RecoveryUnit::setTimestampReadSource() after instantiating an AutoGetCollectionForReadLockFree instance. RecoveryUnit::setTimestampReadSource() invariants that no snapshot is open before it starts. Therefore, this code is susceptible to invariant'ing and crashing given perfect timing of a repl state change causing the explicit RecoveryUnit::setTimestampReadSource(majority) call to differ from the AutoGetCollectionForReadLockFree read source selection.

Another possibility is that the code described can never hit an invariant because the read source selection is always the same, in which case the explicit RecoveryUnit::setTimestampReadSource() call should be removed.