After SERVER-38028, participants block requests for higher txn numbers instead of failing them. So, a transaction started with read concern snapshot following a prepared transaction could have its read timestamp held back due to oplog holes (since the read timestamp will be set to the all committed point).

The following scenario describes the bug:

• Thread 1 prepares txn0 at time 5
• Thread 2 starts new txn1 that blocks on txn0 since it is on the same session
• Thread 3 opens oplog hole at time 8
• Thread 1 commits txn0 at time 6, but commit oplog entry (and txn table update) written at time 9
• On thread 2, txn1 opens storage transaction at all_durable, which would be time 7 since there is an oplog hole at time 8
• txn1 gets a write conflict when writing to the txn table bc it's reading from time 7 and doesn't see the write from time 9