Dynamic HTTP Cache expiry on data responses

[gapple]

Right now caching is set to static values, even though we generally know the exact time that data will change. This results in caches being less effective and precise than possible.
For example:

• Sample data is generated at 06:00
• Request is sent at 06:15, and response is set to one hour expiry
• Request is sent at 07:30
  • Previous response has expired, so cannot be re-used even though no new data is available
• Request is sent at 11:55, and response is set to one hour expiry
• Sample data is generated at 12:00
• Request is sent at 12:15
  • Previous response is still cached, so new data is available but not returned.

Given that we know the interval between sample fetches and estimate generations, we can set the max-age to the interval between the current time and the time new data is expected to be available (or slightly less).
For example:

• Sample data is generated at 06:00
• Request is sent at 06:15
  • Response is cached and set to expire in 5:45 (max-age: 20700)
• Request is sent at 11:45
  • Response hits cache and is returned with max-age: 20700; Age: 19800, so will only be cached for a further 15 minutes
• Sample data is generated at 12:00
• Request is sent at 12:15
  • Previous entry has expired, so a new response is sent with a long expiry period

If a new sample isn't available when expected the max-age can be set to a moderate value until the new data is available. This is more feasible for samples (where the new values will be available in a matter of minutes) and not so well for estimates (which can take hours).

Estimates throw a bit of a kink in this method though, since a placeholder value is stored based on the last sample it was generated from, and the actual estimate may not be available for a few hours afterwards (and there's no indication of the difference between an incomplete estimate and a script timeout). Samples also have a very short window where the estimates row is stored but not all the related estimate_values rows, but this should be solvable by utilizing a transaction.

[gapple]

The issue with there being no way to tell the difference between an incomplete and a failed estimate was resolved with

• 33e8d7829d79ed0c96a7c30c9bd8a307291b3de5: a completed column was added to estimates
• 1fe819f94fc75d6c0df354dd1d700f69fab58cfe: timeouts are tracked internally so that they can be handled

[gapple]

Caching headers are improved in 7777ab0bbdf32d1234f7635724b26e3f73ab4876

New configuration values are required in order to calculate the cache periods.

Responses that we know will not change are set to be cached for a year.