When constructing links we want to read the required host and protocol
information in a dynamic manner from the request for constructing ACME
links such as the directory information. This way, if the server is
running behind a proxy, and we don't know what the exposed URL should
be at runtime, we can construct the required information from the
host, tls and X-Forwarded-Proto fields in the HTTP request.
Inspired by the LetsEncrypt Boulder project (web/relative.go).
Section 8.2 of RFC 8555 explains how retries apply to the validation
process. However, much is left up to the implementer.
Add retries every 12 seconds for 2 minutes after a client requests a
validation. The challenge status remains "processing" indefinitely until
a distinct conclusion is reached. This allows a client to continually
re-request a validation by sending a post-get to the challenge resource
until the process fails or succeeds.
Challenges in the processing state include information about why a
validation did not complete in the error field. The server also includes
a Retry-After header to help clients and servers coordinate.
Retries are inherently stateful because they're part of the public API.
When running step-ca in a highly available setup with replicas, care
must be taken to maintain a persistent identifier for each instance
"slot". In kubernetes, this implies a *stateful set*.
