Improve Cache-Control header parsing and handling

[mjpieters]

Currently, a Cache-Control header on the request has an effect if it has one of two values: no-cache or no-store, in lowercase.

There are two issues with this:

• The header could contain multiple comma-separate directives, and the directives are case-insensitive. The header value should be lowercased, split on commas and stripped on whitespace, then stored as a set, at the very least.
• no-cache and no-store currently are treated as the same, and their effect is if both have been provided. However the two directives mean different things
  • no-cache should be treated as if the backend has no value for the cache key, but the result can still be stored.
  • no-store should be used to skip storing the end-point value in the cache. If the backend still had a response stored it can still be used.

We should probably make it configurable if headers are honoured at all, sometimes you really don't want to allow third-party clients to bypass the cache.

[Bharat23]

I can work on this.
I do have a question on the response header, though.
If either or both no-cache and no-store are used, how should the max-age and Etag in the response header look?