What this fixes

This fixes my original PR #8005

NewServerHTTPS resolved the per-connection local address in a custom http.Server.ConnContext callback:

ConnContext: func(ctx context.Context, c net.Conn) context.Context {
    return context.WithValue(ctx, connAddrKey{}, c.LocalAddr())
},

ConnContext runs synchronously in the http.Server accept loop, before the per-connection serving goroutine starts. For a plain socket c.LocalAddr() is cheap, but when the listener is wrapped by go-proxyproto, Conn.LocalAddr() calls ensureHeaderProcessed(), which reads the PROXY header off the connection (sync.Once). If the header has not arrived yet, that read blocks inside the accept loop and head-of-line-blocks acceptance of every other connection, so connections last longer than they should.

The fix

net/http and http2 already populate http.LocalAddrContextKey from the connection in the per-connection serving goroutine, not the accept loop:

All resolve c.LocalAddr() on the same tls.Conn → … → proxyproto.Conn chain, so the value under http.LocalAddrContextKey is byte-identical to what the custom callback produced — the PPv2 destination address — and it is set off the accept loop on both the HTTP/1.1 and HTTP/2 paths.

So this drops the custom ConnContext callback and the connKey type and reads the framework key directly:

func (s *ServerHTTPS) localAddr(r *http.Request) net.Addr {
    if addr, ok := r.Context().Value(http.LocalAddrContextKey).(net.Addr); ok {
        return addr
    }
    return s.listenAddr
}

The client address is unaffected: it arrives via r.RemoteAddr, which the framework populates natively from c.RemoteAddr() on both paths.

Testing

• go build ./core/dnsserver/ — ok
• go vet ./core/dnsserver/ — clean
• gofmt — clean
• go test ./core/dnsserver/ — ok
• go test -race ./core/dnsserver/ — ok

TestDoHWriterLaddrFromConnContext / TestDoHWriterLaddrFallback stash the address under http.LocalAddrContextKey instead of the removed custom key.