When a /sync request fails, we spin up a keep-alive poll to /_matrix/client/r0
which 400s. We treat any HTTP response code as a success for the purposes of
polling the server. When a successful poll is done, we shoot the current /sync
request in the head immediately (via a hacky abort() on the promise) and retry
the /sync.
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.
BREAKING CHANGE.
Scope each "getAvatarUrl" to be instance methods on the entity it
relates to (Room and RoomMember respectively). By doing this, we
can actually pull out specific state such as the `m.room.avatar`
event more easily rather than keeping it in the global cesspit
of `MatrixClient`.
This was complicated by `getHttpUriForMxc` and `getIdenticonUri`
which were attached to the HTTP API to pull out the `baseUrl` when
crafting the URL. Pull out this dependency out and explicitly pass
it in when crafting the URL. This is trivial to get from
`MatrixClient.getHomeserverUrl()`.
