Accept expired TLS certificate if the fingerprint does not change #7996

TLS certificates expiring is rarely a security problem. In most cases TLS certificate expires because certificate update automation failed. During internet shutdowns certificates automatically updated with ACME fail to renew and expire eventually. Sometimes server owner loses control over domain name and cannot renew certificates afterwards even with DNS challenges. In these cases existing users should not lose access. We also don't want users to "fix" the problem by disabling certificate checks completely when certificates expire.

We should remember the fingerprint of the leaf certificate (EDIT: or the fingerprint of the public key) and accept expired certificates when the fingerprint matches the remembered one. When there is no remembered fingerprint, e.g. after upgrade from the version without this change, we should also accept expired certificates. This will help users who are already using the server with expired certificate to fix the problem by upgrading the client. EDIT: this is not feasible to implement accepting "valid but expired" certificates when we have no remembered fingerprint, see #7996 (comment)

Expired certificates should not be accepted during initial configuration. Otherwise any leaked certificate with a key can be reused forever to setup a new server. Expired key may even be added to the test data, and it should not be usable. If the server certificate cannot be renewed maybe it should not accept new users. For self-signed certificates we need certificate fingerprint pinning via dcaccount, it is a separate problem.

Fingerprint should be remembered per hostname, could be simply a new SQL table with the hostname, last seen fingerprint and a timestamp. If we have not seen any fingerprint for a long time, e.g. because some transport was removed, the record should eventually be cleaned up.