Weather location freshness, timeout, request queueing, and intervals (and configuration thereof)

[stuartpb]

See https://developer.mozilla.org/en-US/docs/Web/API/PositionOptions

I'm wondering how to put all this together. Some thoughts:

• A location request that takes longer than we're planning to wait to make the next request is useless.
  • This probably means we should make the location request timeout no longer than the inter-request interval.
• We shouldn't have more than one weather request in the air at once.
  • That's from start to finish, location request to weather-reported response.
  • If one request, for some catastrophic reason, takes more than 5 minutes... I'm thinking we should just suppress new weather requests until the current one finishes (although this is kind of going on the assumption that it'd be held up in geolocation and not the network: getting held up at the network level brings us right back to the bikeshedding nightmare of Aborting a Fetch).
  • Not handling this edge case could lead to the worst-case-scenario where a response to an older request replaces newer data... although that's probably unlikely enough that it can be put on the backburner.
  • We could also restart the request, like, if the network's the holdup and we could use a new geolocation (though note point above about canceling Promises being this whole awful thing you can't do right now, especially as that holds for Geolocation requests - the importance of timeout as such becomes all the more paramount).
  • We could also do a race between the last one and a new one.
  • We could also batch up our calls, and do a bunch of requests right after another when the request we've been waiting more than 5 minutes for resolves (since the only real reason to space them out like this is to stay under quota, and delayed resolution means we've got quota saved up).
• I'd like to have the data on how long an infinite-timeout or infinite-maximum-age have been known to go, and how the two interact. Is it possible for me to leave both Infinite and then see the UA spend an hour trying to get a fix, then serve me a cached location from yesterday, or last week, or last year? The spec is defined in broad/vague enough terms to not disallow this possibility. (MDN kind of claims an infinite maximumAge will always have some location to return back if the UA can't get a fix, which I figure is probably not true.)

[stuartpb]

On top of printing the current location, maybe it'd do to have some kind of signifier of location freshness, similar to the forecast freshness purple bar proposed in #19 and the mid-day dot proposed in another issue.