Support dynamic zilla configuration via https

[jfallows]

Retrieve initial zilla.yaml configuration via https, then detect a new configuration available at the same URL.

This can be done via infrequent GET if-none-match polling, or ideally using prefer: wait=86400 header instead, allowing the response to unwind only when the 1 day timeout expires or immediately when the content changes.

The reaction to the changed configuration will be the same as for #138 as only the https retrieval mechanism differs.

[bmaidics]

I started looking into this.
RFC specification of the prefer header says (https://www.rfc-editor.org/rfc/rfc7240#section-4.3):

The "wait" preference can be used to establish an upper bound on the
length of time, in seconds, the client expects it will take the
server to process the request once it has been received. In the case
that generating a response will take longer than the time specified,
the server, or proxy, can choose to utilize an asynchronous
processing model by returning -- for example -- a 202 (Accepted)
response.

According to this, it's only an upper bound. So if the config on the webserver is there, it'll immediately return (Tried this with a dummy python webserver). It'd only be good for us if it'd be a lower bound as well. Or am I missing something?

[jfallows]

Yeah, that's correct, when prefer: wait=N is used alone.

However, when prefer: wait=N is combined with if-none-match: <etag> then we can get an immediate response when the new configuration is available, and if the upper bound is reached before then, a 304 not modified can be returned instead. Then Zilla can re-issue the request immediately to detect the configuration change.

The intention is to get the benefits of polling, but waiting at the server instead of the client for less overhead and more timely delivery. This technique is commonly referred to as long-polling.

Please see http.kafka.cache example for more details on how we support this on the server side in Zilla.