Backport of (apigw) resolve service subsets for routes during apigw discoverychain synth into release/1.22.x

[hc-github-team-consul-core]

Backport

This PR is auto-generated from #23294 to be assessed for backporting due to the inclusion of the label backport/1.22.

The below text is copied from the body of the original PR.

---

Description

This change makes API Gateway upstream routing honor the same service discovery policies that are already honored inside the mesh (service-resolver subsets + service-router HTTP matching), so traffic entering through API Gateway is routed consistently with internal mesh traffic.

Why this is needed:

• API Gateway requests were not consistently honoring upstream service-resolver and service-router behavior.
• In subset/default-subset scenarios, synthesized gateway routes could resolve to non-existent/default clusters, causing 50x responses.
• Operators had to duplicate routing policy in HTTPRoute, which is brittle and can drift from service-owned policy.

What changed:

• API Gateway chain synthesis now injects resolver subset definitions from real compiled upstream chains (resolverEntriesFromChains) before compiling synthesized gateway chains.
• Gateway HTTPRoute synthesis now composes HTTPRoute matches with upstream service-router rules (with guardrails/cap), so header/path-based service-router behavior is applied at API Gateway too.
• When a service-router route omits subset but its next resolver target implies one, the subset is propagated so default-subset behavior is preserved.
• Discovery-chain watch options now set protocol from route protocol so HTTP routes are compiled with HTTP-aware chain behavior.

Expected result:

• API Gateway route generation and upstream cluster selection align with mesh behavior for supported composition scenarios.
• No more fallback to invalid default clusters in the reproduced subset-routing case.

Revert plan:

• Revert the commits touching API Gateway discovery-chain synthesis/composition logic to restore prior behavior (primarily in gateway.go, gateway_httproute.go, and api_gateway.go).

Testing & Reproduction steps

Manual reproduction (local):

1. Start Consul in dev mode:
   • consul agent -dev
2. Register multiple instances of one backend service (example: backend-1, backend-2) and configure subsets via service-resolver (e.g. v1, v2, with default subset behavior).
3. Configure service-level routing policy via service-router (header/path based routing).
4. Configure API Gateway + HTTPRoute:
   • consul config write api-gateway.hcl
   • consul config write http-route.hcl
5. Start Envoy sidecars for backend services and API Gateway.
6. Send requests through API Gateway with/without routing headers/prefixes and verify destination subset behavior.
7. Compare Envoy config dumps (API Gateway vs mesh sidecar):
   • Before fix: missing/incorrect route->cluster mapping in subset case, leading to 50x.
   • After fix: composed route rules include expected matching behavior and resolve to valid subset clusters.

Validation performed:

• Reproduced failure case from debug bundles.
• Confirmed API Gateway now emits expected routes/clusters for subset-routing scenario and requests succeed in the previously failing case.

Automated tests:

• No new automated test coverage included in this PR yet (manual verification performed).

PR Checklist

• updated test coverage
• external facing docs updated
• appropriate backport labels added
• not a security concern

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

N/A: no security control changes; routing synthesis/selection behavior only.

---

Overview of commits

• 4ae45d4

[github-team-consul-core-pr-approver]

Auto approved Consul Bot automated PR

[sujay-hashicorp]

closing as targeted only for v2.0.0