Add per-host connection limits to DestinationRule

[prashanthjos]

Add per-host connection limits to DestinationRule

Description

This PR adds support for per-host connection limits in the API by introducing a new perHostLimits field to ConnectionPoolSettings. This feature aligns with Envoy's per_host_thresholds capability for circuit breakers.

Motivation

Currently, Istio's DestinationRule only allows setting a global connection limit for the entire cluster, independent of the number of endpoints. This makes it difficult to properly manage concurrency for destination services, especially in autoscaling scenarios where the number of replicas changes dynamically.

Per-host connection limits allow controlling connections to each individual endpoint, which:

• Prevents overload of individual hosts
• Manages concurrency properly in autoscaling scenarios
• Maintains healthy connection limits without hitting overloaded applications

The underlying Envoy cluster circuit breaker already has this per_host_thresholds capability. Other Envoy-based tools (Envoy Gateway, Contour) have already added this support.

Example Usage

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-per-host-limits
spec:
  host: reviews.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      perHostLimits:
        tcp:
          maxConnections: 10

Limitations

Currently only the maxConnections field is supported for per-host limits, as per Envoy's circuit breaker implementation. Other fields in TCPSettings will be ignored.

Testing

Generated CRD files successfully with make gen
Test case not included due to CRD validation cost limits (will be validated in istio/istio integration)

Fixes #57697

[istio-policy-bot]

🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test?

Courtesy of your friendly test nag.

[prashanthjos]

This uses a simplified structure with a single max_connections field rather than reusing TCPSettings to avoid exceeding Kubernetes CRD validation cost limits. The TCPSettings message contains multiple Duration fields with CEL validation rules that would double the validation cost when reused here, causing the total schema validation cost to exceed Kubernetes limits by ~9%. Since Envoy only supports max_connections for per-host limits currently, this simplified structure provides the same functionality while staying within CRD validation budgets.