xds: Implement proactive connection in RingHashLoadBalancer per gRFC A61

[becomeStar]

Description

This PR implements the proactive connection logic in RingHashLoadBalancer as outlined in gRFC A61.

Previously, the Java implementation only initialized child balancers when a ring-chosen endpoint was in TRANSIENT_FAILURE during a picker's pickSubchannel call. This PR adds the missing logic: when a child balancer reports TRANSIENT_FAILURE, the LoadBalancer now proactively initializes the first available IDLE child if no other children are currently connecting or ready.

This ensures a backup subchannel starts warming up immediately outside the RPC flow, reducing failover latency and improving overall resilience. This behavior was previously present but was inadvertently lost after #10610.

Changes

• Added maybeTriggerIdleChildConnection() to RingHashLoadBalancer to trigger proactive connections.
• Updated existing unit tests to reflect the new connection timing (adjusting requestConnection verification counts).
• Added new test cases to verify:
  • Proactive connection triggering when no other subchannels are active.
  • Suppression of proactive connections when a READY subchannel already exists.

Fixes #12024

[becomeStar]

@ejona86

Thank you for the detailed review.
I've addressed your feedback in the latest push.

• ​Logic location & Quote: Moved the proactive connection condition to updateOverallBalancingState() to align with existing comments and local variables. I've also included the specific quote from gRFC A61 in the comments as suggested.
• Method Refactoring: Renamed the method to triggerIdleChildConnection() and simplified it to focus solely on the triggering action.
• ​Restored Tests: I've restored the deleted verify() lines in the test. I initially removed them out of concern that fixed indexing might make the test brittle if hash results changed. However, since the test remains deterministic and passes, I agree that keeping them provides stricter verification.

​Please let me know if there are any further adjustments needed.

[becomeStar]

I merged the latest master branch expecting the CI tests to pass, but unfortunately, they are still failing.
The logs (403 Forbidden) suggest this is likely an external infrastructure issue rather than a code-related one. I will try triggering the CI again tomorrow with an empty commit to see if the issue resolves itself.

[ejona86]

Thank you!

[becomeStar]

Thank you for the detailed explanation regarding the determinism of the Ring Hash test. I now clearly understand how voidHash() ensures the test remains reliable despite the underlying complexity. I also appreciate you re-triggering the CI and merging the PR. Thanks for your support and for the great learning opportunity.