* Client: Do not send a JWS body when POSTing challenges.
In legacy ACME there was a requirement to send a JWS body that contained
a key authorization as part of all challenge initiation POSTs. Since
both the client and server can reconstitute the key authorization there
is no need to send it and modern ACME expects challenges to be initiated
with a JWS carrying the trivial empty JSON object (`{}`). Some ACME
servers (e.g. Pebble in `-strict` mode) will reject all challenge POSTs
that have a legacy JWS body.
This commit updates the LEGO `acme/client.go`'s `validate` function to
send the correct JWS payload for challenge POSTs.
* refactor: create log.Infof and log.Warnf
* refactor: review DNS providers.
- use one `http.Client` by provider instead of one client by request
- use the same receiver name `d` for all `DNSProvider`
- use `http.MethodXXX`
* refactor: logger init.
If `links["next"] == ""` the early return does not send neither success, nor failure to outer code,
which leads to whole `getChallenges` method being stuck forever, cause it waits for either `resc` or `errc` to receive message.
* [reduce-locking] Prepare for change
* [reduce-locking] Do not lock on http request
* [reduce-locking] Move getNonce and getNonceFromResponse from jws struct cause they do not need access to it
* [reduce-locking] Extract nonceManager
* [reduce-locking] Add test that tries to show locking on http requests problem
* new ChallengeProvider with Present and CleanUp methods
* new Challenge type describing `http-01`, `tls-sni-01`, `dns-01`
* new client.SetChallengeProvider to support custom implementations
Last paragraph of ACME spec, section 6.5:
To check on the status of an authorization, the client sends a GET
request to the authorization URI, and the server responds with the
current authorization object. In responding to poll requests while
the validation is still in progress, the server MUST return a 202
(Accepted) response with a Retry-After header field.
