handle repeated 429s from Observable API with exponential back off

[mythmon]

Framework already respects HTTP 429 rate limit responses from the Observable API. However, it will only retry once. This can sometimes not be enough, especially in cases where there are more than one Framework instances on the same IP, or Framework is not the only thing making request to the Observable API.

This PR changes the retry logic to retry up to 3 times, each time multiplying the Retry-After time the server instructed us to use by successive powers of two. After 3 times, Framework gives up and just lets the request fail.

In the worst case scenario, this would mean Framework waits in total 7 times longer than the server's "Retry-After" header. I've seen this Retry-After header as high as 60 seconds on our API, so this could mean a 7 minute delay.

I'm happy to bike shed on the number of retries or the way in which the time grows. We're also implementing some server side changes to help the situation.

[mbostock]

It looks like rateLimitCount is only incremented once when this._rateLimit === null; am I reading it wrong? Normally I like to combine the increment and check into the same statement so that it’s more obvious that it can never infinite loop.

Suggested change

	if (rateLimitCount >= MAX_RATE_LIMIT_ATTEMPTS) {
	if (rateLimitCount++ >= MAX_RATE_LIMIT_ATTEMPTS) {

[mythmon]

You're right that the rateLimitCount is only incremented when this._rateLimit is null. However, the bug is something different. this._rateLimit is intended to be used for multiple concurrent callers of this function to wait collaboratively. That's not working with this new approach either though. I'll fix it up.