While keeping backward compatibility, I added support for per-nameserver TLS servername specification. This enables users to use upstream dns-over-tls servers from different providers, each presenting different X.509 certificates.

Added tests and updated documentation.

1. Why is this pull request needed and what does it do?

This PR enable users to use upstream nameservers from different dns-over-tls providers. Formerly, plugin only supported a plugin-wide specification of expected TLS server name. With these changes every tls URI in the TO field can have the expected server name specified. Very much like how unbound does it:

Using unbound:

forward-zone:
        name: "."
        forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
        forward-addr: 1.1.1.1@853#cloudflare-dns.com
        forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
        forward-addr: 1.0.0.1@853#cloudflare-dns.com

        forward-addr: 193.110.81.0@853#dns0.eu
        forward-addr: 2a0f:fc80::@853#dns0.eu
        forward-addr: 185.253.5.0@853#dns0.eu
        forward-addr: 2a0f:fc81::@853#dns0.eu

Using CoreDNS with forward:

. {
    forward . tls://2606:4700:4700::1111%cloudflare-dns.com tls://1.1.1.1%cloudflare-dns.com tls://2606:4700:4700::1001%cloudflare-dns.com tls://1.0.0.1%cloudflare-dns.com tls://193.110.81.0%dns0.eu tls://2a0f:fc80::%dns0.eu tls://185.253.5.0%dns0.eu tls://2a0f:fc81::%dns0.eu
}

I had to use % instead of # or @ because other stanzas would either be stripped (as being a comment by Caddy controller) or treaded as part of the IP address. I revamped the use of the zone filter to be a zone splitter instead, making us able to use the % as delimiter.

One tls.Config is instantiated per SNI, each with the tls.NewLRUClientSessionCache capacity set to the number of proxies addressing said SNI. This very tls.Config gets assigned to every respective proxy addressing the same upstream provider.

Former global way of using tls_servername and using this new method is mutually exclusive. Doing so will result in a config parsing error. For backward compatibility tls_servername still can be used, given that no per-nameserver SNI is specified.

2. Which issues (if any) are related?

This PR addresses at least #6059.

3. Which documentation changes (if any) need to be made?

I updated the documentation of the forward plugin, practically no other documentation needs to be updated.

4. Does this introduce a backward incompatible change or deprecation?

No.