fix: prioritise service instance address over Consul node address in GetDownstreamHost

[TomPallister]

Fixes #2325

• Gateway routes traffic to Consul address instead of service instance address in Ocelot 23.3+ #2325

Regression introduced in Ocelot 23.3 where GetDownstreamHost incorrectly used the Consul node's Name as the downstream host whenever a node was present, breaking environments (especially Kubernetes) where Consul nodes and service instances run on different hosts.

Changes

• DefaultConsulServiceBuilder.GetDownstreamHost: Reversed the priority logic to use entry.Service.Address first (the actual service instance address), falling back to node.Address then node.Name only when the service address is unavailable.
• Unit tests: Replaced the existing GetDownstreamHost_BothBranches_NameOrAddress test (which validated the broken behaviour) with two new tests covering all branches of the corrected logic.

Before (broken, 23.3+)

protected virtual string GetDownstreamHost(ServiceEntry entry, Node node)
    => node != null ? node.Name : entry.Service.Address;

After (fixed)

protected virtual string GetDownstreamHost(ServiceEntry entry, Node node)
    => !string.IsNullOrEmpty(entry?.Service?.Address)
        ? entry.Service.Address
        : node?.Address ?? node?.Name;

Test plan

• GetDownstreamHost_ServiceAddressPresent_ReturnsServiceAddress — verifies service address is used even when a node is present
• GetDownstreamHost_ServiceAddressEmpty_FallsBackToNodeAddressThenName — verifies fallback to node.Address then node.Name when service address is empty/null
• All existing DefaultConsulServiceBuilderTests pass
• Full unit test suite passes

🤖 Generated with Claude Code

[raman-m]

To: @TomPallister

Tom, nice to see you! 🙂

The problem is deeper than it may seem at first glance. Please see the related issue #2208.
If the author shows a clear intention to contribute, I am happy to help. However, any potential PR will likely involve more complex changes than a simple method redesign.
I believe we should focus our attention on issue #2208 created by @ggnaegi, but I am not sure when he plans to return to the issue created by him.

Cc: @ggnaegi