Enable conditional responses

[twifkak]

As a follow-on to #406, we should investigate whether we can set an outer etag or last-modified header to enable 304 not modified responses -- saving egress bytes.

We cannot simply propagate the original headers from the backend, because that might prevent the update of the signature -- if a resource remains unchanged for longer than the SXG is valid, then the server will keep saying "304 not modified" even though the SXG is expired.

We cannot simply include the SXG signature in an etag because that is too specific. The signature includes the current date, so it will never match an if-none-match request.

It needs some notion of granulated date -- the date of the resource, rounded to the nearest multiple of N, where N is, say, 25% of the signature duration. This would allow 304s, while still allowing signature (date/expires) updates.

[antiphoton]

Plan

1. The worker responds to the downstream CDN with an etag header containing upstream etag and the SXG signature expiration date.
2. When the worker receives a request from a downstream CDN with etag, the worker responds 304 if both following conditions are met.
   1. The worker sends the parsed etag to upstream original server and gets an 304.
   2. The parsed SXG signature expiration date is at least 3.5 days.

[twifkak]

1. +"and the SXG signature start date"
2. LGTM i. LGTM ii. The current time is before the halfway-point between the SXG start and end date.