The prev_batch value for room responses can be inaccurate

[kegsay]

prev_batch is a token which can be passed to /messages to collect more data. It is sent by the upstream HS and the proxy cannot fudge/fake them. This causes problems in the following situation:

• v2 poller gets 10 timeline events and a single prev_batch in a single response.
• the events and prev_batch are persisted in the proxy's DB.
• the sliding sync client asks for a timeline limit of 7.
• what value do we return for the prev_batch?

The possible solutions are:

• If we return the prev_batch we got from v2, the client will never see the first 3 events in the batch of 10, because the prev_batch starts at the earliest event, not the latest.
• If we return no prev_batch then the client cannot backpaginate at all.
• We could return a LATER prev_batch (if one exists), but this would cause duplicate events. <-- we currently do this.

The current solution is suboptimal due to the duplication of events and the inherent unreliability of the token (it may not exist depending on the precise limit used in the client + responses received by the HS).

A native HS impl can actually calculate these values so does not face this problem.