[API Gateway] Fix use of virtual resolvers in HTTPRoutes

[andrewstucki]

Description

I realized that we were actually improperly munging http route references in synthesized discovery chains for API gateways. What this meant was that when using an service resolver to create a virtual service referenced by an HTTPRoute we wind up writing in the wrong target cluster for a routing rule. This results in the gateway returning "no healthy upstreams".

This change takes into account when the target is just a virtual service created by a service-resolver.

Testing & Reproduction steps

Unit tested and manually verified with the following configuration entries and a mesh-federated Consul setup:

1. TCP Routes

Kind = "tcp-route"
Name = "api-gateway-route"
Services = [
  {
    Name = "tcp-dc-2"
  }
]

Parents = [
  {
    Name = "api"
  }
]

Kind = "api-gateway"
Name = "api"
Listeners = [
  {
    Name     = "listener-one"
    Port     = ...
    Protocol = "tcp"
  }
]

Kind = "service-resolver"
Name = "tcp-dc-2"
Redirect {
  Service    = "tcp-2"
  Datacenter = "dc2"
}

2. HTTPRoutes

Kind = "http-route"
Name = "api-gateway-route"
Services = [
  {
    Name = "http-dc-2"
  }
]

Parents = [
  {
    Name = "api"
  }
]

Kind = "api-gateway"
Name = "api"
Listeners = [
  {
    Name     = "listener-one"
    Port     = ...
    Protocol = "http"
  }
]

Kind = "service-resolver"
Name = "http-dc-2"
Redirect {
  Service    = "http-2"
  Datacenter = "dc2"
}

PR Checklist

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

[nathancoleman]

Suggested change

	gateways: Fix an bug where targeting a virtual service defined by a service-resolver was broken for HTTPRoutes.
	gateways: Fix a bug where targeting a virtual service defined by a service-resolver was broken for http-routes.

[andrewstucki]

merging this as-is for now so it can get backported for the 1.15.3 release, but will circle back to add additional integration tests later