feat(dns): Add configurable DNS SRV priority on a per-service-instance basis.

[drawks]

This PR introduces an optional priority field (0-65535) for service definitions to natively support RFC 2782 failover routing.

DNS SRV responses use the configured value for node, IP, FQDN, and prepared-query results; A/AAAA responses remain unchanged.

This change only affects SRV record construction. It does not change health filtering, weight calculation or prepared-query result selection.

When priority is unset the default priority is left at 1 preserving existing behavior. Explicit priority 0 remains distinguishable from an unset value.

While this feature is quite small it required a lot of mechanical fiddling; the implementation follows the service-definition config checklist and was modeled after #22769 and #16581 which both added a service config field.

The new priority field has been plumbed through the service registration lifecycle, from the API and protobuf layers down to the catalog and peering state.

There is no data migration. Reverting this PR is sufficient to roll back the feature; older code will continue using the existing fixed SRV priority.

Testing & Reproduction steps

1. Checkout to the branch
2. Start a consul dev server go run . agent -dev from the root directory.
3. Register a service with priority set consul services register ./myservice.hcl

service {
    name = "my-service"
    id = "my-service-id"
    port = 8080
    priority = 100
}

4. Query the service through curl localhost:8500/v1/catalog/service/my-service

<snip>
        "ServiceKind": "",
        "ServiceID": "my-service-id",
        "ServiceName": "my-service",
        "ServiceTags": [],
        "ServiceAddress": "",
        "ServiceWeights": {
            "Passing": 1,
            "Warning": 1
        },
        "ServicePriority": 100,
        "ServiceMeta": {},
        "ServicePort": 8080,
<snip>

5. Query SRV records via DNS dig @127.0.0.1 -p 8600 my-service.service.consul. SRV

;; QUESTION SECTION:
;my-service.service.consul.	IN	SRV

;; ANSWER SECTION:
my-service.service.consul. 0	IN	SRV	100 1 8080 baddad-devthang.node.dc1.consul.

Links

Resolves #23728

• RFC 2782 — A DNS RR for specifying the location of services (https://datatracker.ietf.org/doc/html/rfc2782)

PR Checklist

• updated test coverage
• external facing docs updated - will update in a separate PR
• appropriate backport labels added - N/A; no backport is currently planned for this new feature
• not a security concern

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.
• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
  • No additional rollback procedure or data migration is required.
• If applicable, I've documented the impact of any changes to security controls.
  • Not applicable. This change does not modify access control, authentication, authorization, audit logging, or other security controls.

[drawks]

@nitin-sachdev-29 @hashi-derek @srahul3 I see the 3 of you as reviewers and/or code owners in other similar PRs that have been merged. Is there anything I can do to get a reviewer assigned to this?

[drawks]

ping... Anyone want to give me a review here?

I hate to sound like a broken record, but it is still kind of maddening that hashicorp maintainers are so generally unresponsive to external contributions, while clearly being active in various other PRs. My last, single line PR, took 2 months before it got a review. I'll repeat what I said then, It is ridiculous that hashicorp was very eager to send me a t-shirt that proclaims that I am a "core contributor" while also seeming to have no interest in even commenting on my contributions.