Duplicated SectionName Expansion Logic

[sarthyparty]

Describe the bug

The core issue lies in route_common.go:

• Section name refs are expanded once during the build phase (buildSectionNameRefs) and then expanded again later when finding attachable listeners.
• This double-expansion leads to inconsistent behavior and should be refactored so that section name refs are only expanded once, in a single, well-defined place.

Additional context

Several related inconsistencies appear to stem from this section name ref issue:

1. Policies handling (policies.go L463)

   • The logic for merging listener hostnames with route hostnames does not properly handle wildcards.
   • AcceptedHostnames is currently a map of slices of strings, but we need to flatten it.

2. ParentRefAttachmentStatus structure

   type ParentRefAttachmentStatus struct {
       AcceptedHostnames map[string][]string
       FailedConditions  []conditions.Condition
       ListenerPort      v1.PortNumber
       Attached          bool
   }

   • ListenerPort is modeled as a single port, but a ParentRef can attach to multiple listeners, each with different ports.
   • This mismatch may cause incorrect or incomplete status reporting.

3. Refactoring difficulty

   • The correct long-term solution would be to refactor buildSectionName logic, but that risks undoing bug fix [ObservabilityPolicy: got TargetConflict error when creating ObservabilityPolicy for two totally seperated applications #3400].

Summary

• Root issue: Section name ref expansion is happening in multiple places (build + attachment), causing inconsistencies.
• Side effects: Incorrect hostname merging, improperly structured AcceptedHostnames, and overly simplified ListenerPort handling.
• Next steps: A careful refactor of section name handling is needed, ideally consolidating expansion logic without regressing [ObservabilityPolicy: got TargetConflict error when creating ObservabilityPolicy for two totally seperated applications #3400].