This test requires the resumable range deleter to be disabled in order to run. This is because it sets a failpoint to make the recipient shard hang, which means that advanceTransactionOnRecipient will hang on the recipient trying to check out the session, which will prevent the migration from completing.

Unfortunately this is hard to fix in this test because we're using the balancer to do the migration. In addition, we can't avoid setting the migrateThreadHangAtStep2 failpoint because then this call to the recipient could yield Status::OK(), bypassing the error we're trying to hit in the test.

I'm not sure what a good solution is, but fixing this would be required to remove the disableResumableRangeDeleter flag in 4.6.

As a side note for whoever looks at this later, it is not necessary to test three rounds of the balancer and in fact this behavior is incorrect - the first time it will fail due to ExceededMemoryLimit as expected, but the second two migration attempts fail due to ConflictingOperationInProgress since the recipient remains hung at the failpoint even after the first migration fails.