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.
