This change adds support to the JDK for processing the results of a room
search, as well as back-paginating the results.
It treats each search result as a 'context' object, which can itself be
backwards or forward-paginated.
v1 used to clobber events after sending so `.status` would be `null`. v2 is
smarter and just clobbers the `.event` data so references to the local echo
event would reflect the new event. However, the `.status` in this case would
still have the old value (SENDING), so make sure to reset it after the 200 OK
from sending the event.
This fixesvector-web/vector-im#536
The bug here is that we were assuming `setTimeout` would fire after the
requested time. This is not true when the machine is asleep. We now timestamp
before and after `setTimeout` and reset the attempt count if we have waited
more than twice what we originally requested. This allows for some jitter which
is to be expected.
The ability to set a local timeout is applicable to any request, so move it
to http-api.js - We only use this on /sync requests currently. This simplifies
the SyncApi since it doesn't need to worry about it anymore -- the request
promise just gets rejected if the timer expires.
Whilst testing I noticed a weird anomaly which I cannot explain. Playing with
Chrome's network debugger, once you recover from a black hole (0kbps, 90s RTT)
the subsequent requests take 20s to return *even though there is no throttling*.
This was causing issues when using a local timer of timeout= and BUFFER_PERIOD_MS
when timeout=1 due to attempts>1 - they were being knifed before the response
could return. The 20s latency was entirely artifical (checked synapse logs and
they were sub 1s), but I cannot find anywhere in the JS-SDK or browser-requests
where this would be the cause. This persisted even when BUFFER_PERIOD_MS was
changed from 20s to 10s.
