Add support for Caddy-style Automatic HTTPS to pd

[hdevalence]

Is your feature request related to a problem? Please describe.

Following #1405, we have a way for pd to serve TLS connections with HTTPS, using user-managed certificates. This is good to get started, and is useful for deployment environments that have some tooling for certificate management (e.g., cloud infrastructure with cert tooling), but doesn't help much for individual or development deployments.

Describe the solution you'd like

pd should have support for Caddy-style Automatic HTTPS, and it should always use HTTPS for all RPC endpoints, in the same way Caddy does: self-signed certs for localhost, and Let's Encrypt for public DNS names.

To support ACME, we can use a library like https://crates.io/crates/rustls-acme

Additional context

We'll also want to have TLS support for pviewd, but that could be done separately, because there's a different trust and threat model -- pviewd has secret data, so the transport security story should include authentication.

[hdevalence]

Rough notes on how we could combine rustls-acme with tonic:

rustls-acme is an easy-to-use, async compatible ACME client library for rustls. The validation mechanism used is tls-alpn-01, which allows serving acme challenge responses and regular TLS traffic on the same port.

https://docs.rs/rustls-acme/0.5.1/rustls_acme/#high-level-api

The result is a Stream of incoming TLS connections. The tonic API's Server::builder() can configure hardcoded TLS certificates, but then after add_service turns into a Router, with a serve method (which we use). Using view-source on docs.rs, we see that serve internally wraps serve_with_incoming. Perhaps we can combine the rustls-acme with serve_with_incoming?

[conorsch]

Removing from testnet milestone, in favor of #1886, which is the parent epic. Will continue to pull subtickets from that epic.

[hdevalence]

Closed by #1406