Support short-term cert expiry

[twifkak]

trafficstars

Currently, amppkg only loads the cert file at startup. If it expires while the packager is running, the packager continues to sign with it and serve it. Instead, it should attempt to reload automatically starting a few days before expiry, and continuing at some regular interval until no longer imminently expiring. If the cert is expired, it should stop signing exchanges, and log a warning.

In addition, it should serve the cert-url with an http expiry no longer than the cert expiry (as a follow-up to #85).

[twifkak]

This will be much more important as of WICG/webpackage#383.

[twifkak]

Restarting the server every 90 days is an option. Perhaps not a particularly pleasant one, but perhaps not so bad in this world of coordinated containers.

[twifkak]

Cert renewals will have a different cert-sha256 and hence a different cert-url and generate different signatures. If so, we should decide whether to continue serving the old cert at the old URL (up until expiry). We may get a timeline like:

1. AMP cache requests SXG, amppkg provides.
2. amppkg has new cert.
3. AMP cache requests cert-url, amppkg 404s.

There may be an arbitrary amount of time between (1) and (3), though likely usually small. Though the AMP cache is free to respond to the 404 by doing a GOTO 1.

I'm leaning to 'no' for simplicity, since AMP Caches have some workarounds available.

Alternatively, maybe we should reconsider data: cert-urls.

[twifkak]

Update:

• We should support hosting old and new cert at same time. (Does this mean we'll need to change the toml to allow a list of cert paths?)
• Optional: Allow adding new cert without restarting. (Either inotify or SIGUSR1.)
• Required, but later is ok: Integrate an ACME client library.

[twifkak]

Sorry for the noise; changing things back since I see from the comments there is other stuff than just the tests. Split the tests off into #433 since that seems fixit-sized.