Fix NCCL Error 7 by removing eager_connect_single_device

[d4l3k]

Summary

• Remove eager_connect_single_device from ProcessGroupNCCL._create_pg to fix "NCCL Error 7: operation in progress" failures
• In non-blocking NCCL mode (blocking=False), eager_connect_single_device starts an async communicator init that cannot be waited on through Python APIs. The first collective then fails because the init hasn't completed.
• Without eager_connect, the communicator is lazily initialized by the first collective, which properly handles the async init inside its ncclGroupStart/ncclGroupEnd context.

Test plan

• CI GPU tests (QuantizedAllReduceTest) should pass, which have been failing since ~Dec 2025 due to a PyTorch nightly regression in non-blocking NCCL + eager_connect interaction

[JiwaniZakir]

The fix removes eager_connect_single_device unconditionally, but the comment specifically calls out that the problem occurs in non-blocking mode (blocking=False). If opts can also represent a blocking configuration, removing eager connect in that case is an unnecessary regression — blocking mode could safely call eager_connect_single_device and would benefit from the earlier communicator initialization and faster first-collective latency. A more precise fix would be to check opts (or whatever flag controls blocking) and conditionally skip the call only when non-blocking is set, e.g.:

if not opts.is_high_priority_stream: # or whatever the blocking flag is
backend_class.eager_connect_single_device(...)

Additionally, there's no test covering the scenario described — a test that creates a ProcessGroupNCCL in non-blocking mode and runs a collective immediately after init would both prevent regression and document the expected behavior. Without it, a future refactor could silently reintroduce the bug.