Fix Consul API Client Service Transaction Unmarshall Error

[jzou-rbx]

Description

This PR fixes the Golang Consul API Client Library Unmarshalling error when using the Transaction API with Service that has TaggedAddresses, see #22180 (comment).

Below is a summary of the current Service Transaction Workflow when using the Golang Consul API Client Library:

1. The Txn client specifies Service information to update as an api.AgentService in an api.ServiceTxnOp to submit to the Agent Txn endpoint.

2. In the Agent Txn endpoint, it converts the api.AgentService to a structs.NodeService
   that is used internally for applying the transaction.

3. After the transaction is applied, the structs.TxnResponse that is returned to the client contains the Service information as a structs.NodeService in the structs.TxnServiceResult.

4. The Txn client tries to decode the returned response as an api.TxnResponse which uses api.CatalogService for the Service TxnResult.

5. When a Service has TaggedAddresses, the decoding fails with json: cannot unmarshal object into Go struct field CatalogService.Results.Service.TaggedAddresses of type string. This is because structs.NodeService has TaggedAddresses as a map[string]structs.ServiceAddress, while api.CatalogService has TaggedAddresses as a map[string]string which is intended to be the node's TaggedAddresses and the Service's TaggedAddresses` is in ServiceTaggedAddresses field.

The proposed fix here is to change the Golang Consul Client Library to use api.AgentService for the Service TxnResult which has fields that are compatible for conversion from structs.NodeService
returned from the agent endpoint.

This change will require applications that use the Golang Consul Client Library for Service Transactions to do a small code change once they choose to upgrade the library to the new release (they will get notified with compile errors). Considering that any such clients are already in a broken state (if there are any such users besides us), it should be fine ok require such a change. api.AgentService appears to be the more appropriate Service TxnResult type, it matches the Txn input type and it is the return type for other endpoints such as health/service.

If we do still want to maintain api.CatalogService as the Service TxnResult type, then we could just add a best-effort conversion from api.AgentService to api.CatalogService before returning in the client library.

PR Checklist

• updated test coverage
• not a security concern

[nitin-sachdev-29]

have raised similar PR #22248 because of vercel failure