Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour:

1. Remote prepare for txA acquires lock K
2. Remote prepare for txB blocks waiting for lock K
3. The topology changes, and the txA prepare is retried
4. The txA prepare times out, because it waits for pending transaction txB to finish.

So we have to make txA somehow know that it already has the lock after it received an UnsureResponse for the prepare command, and skip waiting for pending transactions.

I found the problem in a random failure of DistributedFourNodesMapReduceTest on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely.