tls: Add alpn to managed HTTPS records

[steadytao]

Summary

This adds alpn to the HTTPS records Caddy already manages for ECH publication.

This is a good fit for Caddy because ALPN is derived from Caddy's own configured HTTP protocol support. If Caddy is already authoritative for the HTTPS RR it is publishing, it is also authoritative for the effective ALPN set exposed by that server.

This PR keeps the scope deliberately narrow.

It does not add automatic ipv4hint or ipv6hint. Those do not fit Caddy's information boundary nearly as well because Caddy is often not the source of truth for client-facing IP hints. In many real deployments, Caddy may be behind NAT, behind a CDN, behind a load balancer, behind Kubernetes ingress, using split DNS or serving through separately managed authoritative DNS. In those cases, deriving IP hints from local listener state would be misleading in the best case and wrong in many cases and wrong hints are worse than omitted hints.

Concretely, this change:

• plumbs per-domain ALPN values through TLS server-name registration
• derives HTTPS RR ALPN values from the effective HTTP server protocol configuration
• publishes alpn alongside ech when Caddy updates managed HTTPS records
• preserves other existing HTTPS RR params

One implementation detail worth calling out is that Automatic HTTPS runs before later provisioning fills in the default protocol set so the helper derives the effective protocol set from the raw server config rather than relying on already-normalised Server.Protocols. That preserves the common default case instead of silently omitting ALPN.

Tests

Added focused tests to verify:

• default protocol mapping to HTTPS RR ALPN values
• listener protocol overrides
• exclusion of h2c
• server-name ALPN registration and deduplication
• preservation of existing HTTPS RR params when adding ech and alpn

Implements/closes #7403.

Assistance Disclosure

No AI was used.

[steadytao]

Just transferring Matt's comments to make this a bit easier to read.

Regarding aacb430

modules/caddyhttp/autohttps.go (557-559)

• It would be really awesome if we didn't have to repeat the default protocol list... wonder if there's a way to avoid that.

modules/caddyhttp/autohttps.go (176)

• Since I don't think anyone is using the RegisterServerNames API (yet)? we could probably just break this and add the second arg, although, before we do more on this I might want to look carefully and see if there's a better way we can convey the ALPN data to the ECH code.

modules/caddytls/tls.go (729-732)

• Here's that list again. I wonder if we can avoid repetition

[steadytao]

I took the narrower route here and pushed the ALPN data through the existing server-name registration path, rather than layering on a second parallel mechanism just for ECH. Basically RegisterServerNames now carries optional ALPN values and the TLS app stores that alongside each registered name so the ECH code reads from one source of truth instead of trying to reconcile separate name and ALPN state.

This should not break existing setups in practice. The API is explicitly experimental and within Caddy the behavioural change is only that ECH publication now gets the effective ALPN data from the same registration flow used to collect names. The default protocol/ALPN lists are also centralised rather than changed so 904f9fd is mainly just deduplication and data-shape cleanup.

• https://github.com/caddyserver/caddy/pull/7653/changes

[mholt]

Thanks, this is making progress; I started a review but realized the last comment here is a big ask. What do you think?