remote replica concurrent transaction start latency

When there is data to pull for a remote replica, we serialize transaction starts to make sure only one remote pull happens at a time. Under heavy write throughput, customers with concurrent reads have observed increasing latency on successive client reads when there is data to pull, e.g.:

Connection 1: 500ms
Connection 2: 1000ms
Connection 3: 1500ms

This is an indication that these clients are queueing up behind one another and then doing their own pull after waiting for the previous client to complete its pull.

Expected behavior is that any transaction that was waiting on another to complete a pull uses that last successful pull as its transaction start point, rather than start its own pull.