Abhishek/fix api gw peering

[LordAbhishek]

This PR adds api gateway peering unit test cases and fixes couple of issues discussed below with “api gateway when operating in peering”.
Please note: This PR merges 3 other small PRs.
#23369
#23370
#23371

Issues details (Theoretically): API Gateway issue with peering and fix.docx

Details:

1. Whenever we generate the endpoints config for api-gateway, within makeUpstreamLoadAssignmentForPeerService (xds/endpoints.go), it always fetch local_mesh_gateway_endpoint only from connect-proxy, instead of api-gateway cfgSnap.
   localGw, ok := cfgSnap.ConnectProxy.WatchedLocalGWEndpoints.Get(cfgSnap.Locality.String()).

   If not fixed, api-gateway’s cluster for peering will always endup with no endpoints, when meshGatewayConfig.Mode is local.

   Fixed it to fetch the endpoints based on cfgSnap kind. PR

2. Whenever we generate the endpoint config for api-gateway, within endpointsFromDiscoveryChain (xds/endpoints.go), it fetches meshGatewayConfig to configure endpoints, if it needs to point to local meshGateway or remote meshGateway.
   Here also, this method always fetches meshGatewayConfig.Mode from connect-proxy, instead of api-gateway. So, mgwMode is always nil and nil defaults to remote meshGatewayConfig.Mode.
   So, even if we configure the mesh-gateway to local, it will always fallback to remote.

   Fixed it to fetch the meshGatewayConfig based on cfgSnap kind. PR

3. In continuation of issue 2, where we have to fetch the meshGatewayConfig for api-gateway, we never have had the meshGatewayConfig in api-gateway upstreams. 

   Found that handleRouteConfigUpdate (proxycfg/api_gateway.go) which updates the upstreams for api-gateway, was skipping to propagate meshGatewayConfig to upstreams. 

   Fixed it by adding meshGatewayConfig within upstream object. PR

4. Whenever we generate the cluster config for api-gateway, within makeUpstreamClustersForDiscoveryChain (xds/clusters.go), it always generates the cluster without endpoints.
   As we know that whenever any service upstream endpoints is hostname, we have to send it via clusters config to CDS, because envoy is not able to resolve hostnames as EDS. 

   If not fixed, this would results envoy config without endpoints for some clusters (those whose upstream are of hostname type).

   Fixed it to generate cluster based on upstream endpoint type as done for connect proxy or mesh gateway. PR

How the fix is tested:

Unit test cases:
$ go test ./agent/xds -run 'TestAllResourcesFromSnapshot/.*/api-gateway-with-peers-mesh-mode-(local|remote)-and-upstream-is-(hostname|static)' -count=1 -update

ok github.com/hashicorp/consul/agent/xds 0.491s
$ go test ./agent/xds
ok github.com/hashicorp/consul/agent/xds 1.924s
$ go test ./agent/proxycfg
ok github.com/hashicorp/consul/agent/proxycfg 5.105s

Consul-k8s acceptance tests:

consul-ent PR (same as this one):
Ran the consul-k8s workflow with the patched consul-ent image.
All peering test ran fine on both EKS and Kind.
Kind test: https://github.com/hashicorp/consul-k8s-workflows/actions/runs/22376072101
EKS test: https://github.com/hashicorp/consul-k8s-workflows/actions/runs/22376066354

[anandmukul93]

LGTM . need to see if all acceptance tests pass. and need to rerun the multiport tests as well post this.

[hc-github-team-consul-core]

📣 Hi @LordAbhishek! a backport is missing for this PR [23454] for versions [1.18,1.21] please perform the backport manually and add the following snippet to your backport PR description:

<details>
	<summary> Overview of commits </summary>
		- <<backport commit 1>>
		- <<backport commit 2>>
		...
</details>