Many commands reference cluster-side state, which is only valid on the original cluster.

An example of this is the cursor returned from a find command which produced more results than a single batch. A client is expected to make a subsequent getMore request, and provide the same cursor.

During replay, a find request may be replayed, and will result in a different cursor. A subsequent getMore would still reference the old cursor, and would fail.

The replay client needs to track state, to allow re-writing affected queries. In this case, for every cursor observed in a response, the client needs to maintain a mapping from "recorded cursor" to "replay cursor". Additionally, this cursor mapping should be removed when no longer needed, to avoid excess memory usage.

Initially, only cursor needs to be handled, but as other similar re-writes are anticipated, the design should be made easily extensible.