When TaskExecutorCursor receives a multi-cursor response to the remote, and pre-fetching is enabled, it schedules getMores on each cursor: one via the current TaskExecutorCursor, and one via the constructors of each new TaskExecutorCursor it creates to handle the additional responses (see the call to processResponse here for the first cursor's getMore, and the call to processResponse here for the getMores for each additional cursor created.

These getMores can reach the network in any order. However, the MultipleCursorsGetMoreWorks test expects a particular ordering of the getMores reaching the network. Before connection-pinning was enabled, this was fine, because the network mocking infrastructure for the non-pinning case is guaranteed to receive the requests in the order they are scheduled by the TaskExecutorCursor response-processing thread. However, the mocking infrastructure for the pinning case is more like the "real" network, in that it can receive these requests out-of-order.

We should fix the test to be resilient to the getMores for each of the multiple cursors arriving at the network in any order.