Rate limit mitigation (and minor fixes)

[AnyOldName3]

This is kind of three unrelated things, so sorry for lumping them into one pull request.

• An improved return value when Bing Maps has no data for a particular tilekey
• The fallback mechanism introduced in #41 meant that high-LOD tiles would get created even if they only had low-LOD data, so avoid doing that.
• Extend the retry system for HTTP requests to also happen for 429 Too Many Requests errors. There's more detail in the commit message. This puts a massive dent in the number of failed tiles when zoomed in with Bing Maps, so you can get roughly a whole extra zoom level or two before overwhelming the API.

[gwaldron]

Thanks. I agree it works much better with Bing. The randomizer is a little weird but we will go with it for now :)

[AnyOldName3]

I had the CSMA/CA system from WiFi in mind (the collision avoidance part typically works the same way as I've done things here), so it wasn't my own invention. It did seem to be an improvement over a fixed time in my not-very-empirical testing, without needing as much of a delay on average.

There's still a bit of a problem in that the dependency cache thing I did a few days ago won't cache failed requests, which was intentional so it didn't doom a rate-limit-induced failure to affect future requests for the same tile, but also means that when a request fails because there's no data for a particular region at a particular level, it'll happen again for any other composite tile that covers the same source tile, and counts towards the rate limit.