Fluent API for Client-Side Load Balancing (bypass DCP proxy when needed

[gimmickj]

Feature Request: Fluent API for Client-Side Load Balancing (bypass DCP proxy when needed)

Problem

• DCP Proxy opacity: In local Aspire/DCP, every HttpClient points at a single proxy endpoint (localhost:xyz). Even if .WithReplicas(3) is configured, the client never sees multiple targets, so client-side load balancing (CSLB) or health filtering can’t be exercised.
• Kubernetes parity gap: When we move to K8s, we often want headless services or direct Pod resolution (especially for gRPC). Microsoft.Extensions.ServiceDiscovery doesn’t expose a fluent, code-first API to express “use Aspire discovery + RoundRobin” or “bypass proxy in dev to test CSLB logic before deploying.”
• gRPC mismatch: gRPC in .NET already supports client load balancing via ServiceConfig. Having only server-side proxying breaks the native gRPC design (single subchannel).

Desired API

builder.Services
    .AddHttpClient("orders", client =>
    {
        client.BaseAddress = new Uri("http://orders-service/");
    })
    .AddServiceDiscovery()        // logical name → multiple endpoints
    .AddRoundRobinLoadBalancer(); // explicit strategy in code

Key Requirements

1. Simple fluent API (AddRoundRobinLoadBalancer, AddRandomLoadBalancer, etc.).
2. Works with AddServiceDiscovery() (Aspire discovery or Kubernetes discovery, including headless services).
3. Routes only to healthy endpoints (respect readiness/health checks).
4. Ability to bypass the DCP proxy locally so teams can test CSLB before shipping to Kubernetes.
5. Parity with tooling like Steeltoe or Project Tye, which already exposed these capabilities.

Additional Context

• Many teams coming from Steeltoe.Discovery.Consul or Tye expect code-first control over client load balancing.
• Config-only approaches (appsettings) aren’t ideal for library authors or ServiceDefaults packages that need to enforce policies.
• gRPC & high-throughput scenarios benefit from direct Pod routing; DCP proxying hides the underlying architecture and prevents realistic perf testing.
• Once deployed to Kubernetes, we’d like Aspire + Service Discovery to behave more like gRPC’s ServiceConfig, with strategies selectable in code.