Expose GatewayServices endpoint in HTTP API

[freddygv]

This PR moves the GatewayServices out of internal and into the Catalog API.

The reason for doing this is to facilitate 3rd party integrations, such as when proxies other than Envoy wish to be configured as a gateway for Consul's service mesh. This is the endpoint we use internally to determine what services an ingress/terminating gateway will route to.

There were a few things that needed to happen, so this is best consumed by commit:

1. Moved the RPC endpoint to be under the catalog, since that's where the state store operations are. (mostly plumbing)
2. Exposed an HTTP endpoint.
3. Refactored usage of structs.ServiceID to use structs.ServiceName (mostly plumbing). This was because the JSON output of ServiceID has the following fields, which could cause confusion when users expect a service name:

{
	"ID": "$id",
	"Namespace: "$ns"
}

4. Added docs

Remaining TODO:

• Fix up Enterprise

[crhino]

Few comments from initially looking over the code.

I was slightly concerned about the big rename of ServiceID -> ServiceName potentially causing some changes in other API return values, but from going through the rename it looks like everything that was changed was just internal bookkeeping. No return values of state store methods/endpoints changed. 👍

As for the API endpoint, /v1/catalog/gateway-services/ lines up nicely with /v1/catalog/node-services/. The other potential I thought of was /v1/connect/gateway-services/, since it relates to service mesh, but no strong opinions there.

Will test it out locally next.

[crhino]

Thinking more, I do wonder if gateway-service is the correct name for an API, since we are not really returning much of the same data that the other *-service endpoints do.

Going by current conventions, I think /v1/catalog/gateway-services/ accurately describes "Return to me a list of services associated to a specific gateway", but the data model we return back is very different than /v1/catalog/node-services/. The data model is more of a mapping than the other catalog endpoints. Thoughts?

[banks]

Great points @chrino.

I think on the whole /v1/catalog/gateway-services/ seems like a logical home for this. I'm OK with it also returning a slightly different format than other catalog endpoints - we already return different result formats for /catalog/services (just a list with tags) and /catalog/node/:node (which despite the name is mostly list of services on a single node. The other /services or /connect endpoints are for generic discovery but at specific to a single target service.

Since the use-case here is different it makes sense to me that the format is different since we are querying for a mapping - it's close to the /catalog/node/:node in the sense that it's a mapping of services exposed through a specific gateway service but the actual data needed is different to that seems OK to me.

So yeah, didn't read all the diff yet but the API decision here LGTM 👍 .

[crhino]

We have mismatched docs and implementations here, I think we probably want 3 metrics here, like catalog_node_services:

1. consul.client.api.catalog_gateway_services.
2. consul.client.api.error.catalog_gateway_services.
3. consul.client.api.sucess.catalog_gateway_services.

The docs have success and error, while the implementation has consul.client.api.catalog_gateway_services. and error.

[crhino]

Ok, tested it out locally and it looks good. 1 remaining comment around making sure to add the success metric for the endpoint and updated the telemetry docs, but otherwise looks good to me. 👍