SSL overlap: move from admission-time detection to reconcile-time status condition (Gateway API OverlappingTLSConfig)

Background

The SSL conflict detector currently runs only in the admission webhook (ValidateCreate / ValidateUpdate for Gateway, Ingress, ApisixTls). apisix-ingress-controller#2810 / api7-ingress-controller#437 changed it from denying an overlapping SSL object to emitting an admission warning, because denial was both incomplete and a backward-compatibility break (an unrelated edit to an object that already coexists with an overlapping one got rejected).

Warning at admission is only a partial answer. This issue tracks moving to a reconcile-time, Gateway-API-aligned model.

Why admission-time detection is insufficient

The webhook only fires on object create/update, so it never sees conflicts that arise from:

• a certificate rotating inside its Secret (two previously-agreeing objects diverge, no object event),
• a GatewayProxy / IngressClass change moving an object into a different group,
• the webhook being disabled (failurePolicy: Ignore),
• objects created before the webhook was installed.

None of these produce any signal today.

Proposed direction (Gateway API OverlappingTLSConfig)

Gateway API specifies that overlapping SNIs are allowed, with the data plane serving the longest matching SNI, and v1.3 defines the OverlappingTLSConfig listener condition that controllers MUST set on overlapping listeners, with a documented tie-break (oldest creationTimestamp, then namespace/name).

• Detect overlapping TLS host/cert config during reconcile (not only admission), reusing the existing sslutil.HostsOverlap / ClientConfigHash logic.
• Surface overlap as a status condition on the affected objects (Gateway: OverlappingTLSConfig; define an equivalent for ApisixTls / Ingress).
• Document/confirm the deterministic data-plane resolution (longest SNI; then creationTimestamp; then namespace/name) so operators know which certificate wins.
• Keep the admission warning as an early, apply-time signal.

Scope note

This is the reconcile-side follow-up to the warn-only detector in #437 / apisix-ingress#2810. Should be synced to apisix-ingress-controller as well once the design is agreed.

Review the existing admission paths (ValidateCreate/ValidateUpdate) and the sslutil.HostsOverlap / ClientConfigHash logic before tracing the relevant reconcile flow. Define the agreed Gateway API condition and equivalent conditions for ApisixTls and Ingress, including deterministic resolution and documentation. Done means reconciliation reports overlaps, admission warnings remain, and the design is synced to the related controller.