Actual resolution of the DNS zone name in Lexicon-based DNS plugins

[adferrand]

First, let's recap the situation this PR and the code it replaces is meant to handle.

There is a tricky corner case to manage in DNS-01 challenges: the issuance of certificates for third-level or more domains (eg. sub.domain.net). Indeed given that a DNS-01 challenge is supposed to create a TXT record on the `_acme_challenge.sub.domain.net FQDN, the acme client has to determine if:

• a TXT of name _acme_challenge.sub has to be created in the DNS zone domain.net (usual case)
• or a TXT of name _acme_challenge has to be created in the DNS zone sub.domain.net because the DNS zone domain.net declares a domain delegation for sub.domain.net.

The current approach in Lexicon-based DNS plugins is to basically try recursively to setup the underlying Lexicon client on an theoritical DNS zone sub.domain.net, then domain.net, then net. The first zone where the authentication does not fail is selected as the actual DNS zone to operator.

This works, but it has several drawbacks:

• this approach generates useless bad requests against the DNS API
• it requires to define methods specific to each DNS provider to extract from all possible errors generated from Lexicon the ones that corresponds to a bad authentication because of a non-existent DNS zone, which is a brittle process to maintain
• this itself requires an inner knowledge of the underlying DNS API and Lexicon internal logic, which increase the difficulty to implement a DNS plugin

Until recently Lexicon had a similar limitation with third-level or more domains, and needed an additional configuration parameter, delegated to instruct it of the actual DNS zone if its name was not a second-level domain.

Since version 3.17.0, I have introduced a proper resolution of the DNS zone for a given FQDN on which the record should be created. This is enabled by the boolean configuration parameter resolve_zone_name, and it leverages the method dns.resolver.zone_for_name from dnspython.

This PR raises the requirement of Lexicon to 3.17.0 and leverage this mechanic in the recent base authenticator class LexiconDNSAuthenticator introduced by #9746. As a consequence, the workaround introduced by #9821 is not needed anymore. I also removed the tests related the recursion of authentication attempts.

Please note that I do not change the behavior for the old base classes, considering that the plugins in the community have to migrate anyway as part of the plan described in #9776, and so would benefit of this improvment as part of the migration process. Please not also that this PR do not change the existing functionality and so do not manage resolution of CNAMEs. This would not have its place in Lexicon, since it is just a DNS utility. In my opinion resolution of CNAMEs is part of the DNS-01 challenge strategies and should be taken care by the acme client (I do that in dnsrobocert for instance).

[MeggyCal]

Hi, are you please going to continue with this PR? Lexicon-based tests are failing again in my project and I am hoping for this PR to fix it.