See design doc for details. SERVER-61141 should've accomplished what we need. Check that the multitenant migrations tests already cover all the TenantMigrationRecipientAccessBlocker cases we need to test for Merge.

EDIT:

In-memory RTAB is used to reject user donor snapshot reads earlier than rejectReadsBeforeTimestamp  after shard merge commit because the first version of shard merge doesn't preserve/copy donor history. In-memory RTAB is deleted once the recipient state document is deleted. Currently, TTL delete the state document after shard merge completion with GC delay of tenantMigrationGarbageCollectionDelayMS (default is 15 mins). This is risky as there is no guarantee that R’s oldest timestamp >= rejectReadsBeforeTimestamp after GC delay. So, after merge commit, we can have readers trying to do donor data reads at snapshot earlier than rejectReadsBeforeTimestamp after GC delay. And, there will be nothing to prevent those readers from reading inconsistent data, violating snapshot read guarantees.

(The same problem exists in MTM protocol as well).