Fixes #68 - Handle Backoff header.

[n1k0]

r=? @leplatrem @Natim

[n1k0]

I just realized we need a request queue in order to avoid getting a disordered requests chain when the backoff release timestamp is reset. That's slightly more complicated than initially expected; I wish we'll actually use that feature :)

[n1k0]

This is really a bunch of work; especially, we'd need to think what are the consequences of not having the response immediately while requests are queued, and what happens precisely when a bunch of them are performed when the backoff release timestamp is reached.

A very simple solution would be to simply trigger and error when a Backoff header is received, and that would be developers' responsibility to hold on performing more requests and/or handling the queuing by themselves.

I'm voting for the latter, though would love getting some feedback :)

[Natim]

Actually the Backoff is not an error. IMHO it is better not to do anything (like queuing or stopping requests) rather than raising error.

[n1k0]

After discussion, here's the new plan:

• On Backoff release timestamp being set, reject any call to Collection#sync();
• Provide an option to Collection#sync() to force the synchronization even if a backoff is ongoing.

[n1k0]

@Natim r=?

[Natim]

Maybe ignoreBackoff is better?

[n1k0]

That's better indeed, will update.

[n1k0]

@Natim r=? regarding your comments.

I'll update this patch to allow running integration tests against a kinto server instance configured to send Backoff headers, for safety. Hold on merging in the meanwhile.

[n1k0]

Note that this patch embeds a fix for Kinto/kinto#148; We could land this as is and remove the fix when the related issue is closed, or wait for a new kinto version to be released (I really want to rely on stable releases for tests).

[Natim]

r+ I agree we should not wait on Kinto/kinto#148 to land this PR