While performing an index build, we perform a write acquisition on the collection we are building, but then also try to get the number of documents in that collection so that we can track our progress.

Once the read path for the replicated fast count project is fully integrated, that means that calls like this will attempt to read from a replicated collection. When a simultaneous index build is running and building on a secondary, reading from a replicated collection will try to use kLastApplied to respect batch boundaries. However, the earlier write acquisition will have set the readSource of the recoveryUnit to use kNoTimestamp.

As of SERVER-101416, we guard against this behavior (nested acquisition trying to read from kLastApplied while recovery unit already has kNoTimestamp set) with a tassert.

However, because we are tracking index build progress here, it should be acceptable to continue reading from latest and get potentially mid-batch results. We can explicitly indicate that we are knowingly reading from latest on a replicated collection on a secondary and bypass the guard in these particular cases.