The jstests/noPassthrough/read_concern_snapshot_yielding.js test exercises behaviors when a transaction is in the state of having acquired a snapshot but before it begins to read documents out of collections. To reliably reach this state, the test sets the internalQueryExecYieldIterations to 2 and then sets the setInterruptOnlyPlansCheckForInterruptHang failpoint, which has the combined effect of having the transaction's first collection scan seek to the first record, and then hit the failpoint just before pulling out the first record. This approach has a few issues:

1. If the collection being scanned is clustered, one yield iteration doesn't guarantee reaching the first record, and the number of yield iterations required to reach the desired state is nondeterministic. (This exact issue began appearing during development of SERVER-80862)
2. It's difficult to reason about where and when the failpoint gets reached.
3. This is the only use case of this failpoint.

Refactor the test to use a strategy for reaching the "acquired snapshot" state without relying on this approach, preferably away from the use of yield iterations to avoid the issue with clustered collections and preferably such that we can remove the old failpoint. One proposed implementation:

1. Define a new failpoint that is specific to reaching the start of a collection scan, but not returning any documents.
2. Have the test use that failpoint and remove the code from the test that sets yield iterations.
3. Delete the old failpoint if this is still its only use-case.