Backport of Refactor Txn API to use AgentService and add TaggedAddresses support into release/1.15.x

[srahul3]

Backport

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

The person who merged in the original PR is:
@nitin-sachdev-29
This person should manually cherry-pick the original PR into a new backport PR,
and close this one when the manual backport PR is merged in.

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]

Since 1.15 is an older version the changes are not merged in CE. The required changes are merged in enterprise repo.