[CELEBORN-2331] Parallelize batch open stream client creation

[sunchao]

Why are the changes needed?

CelebornShuffleReader creates data clients serially for each distinct worker before the existing parallel BATCH_OPEN_STREAM phase. If one or more worker endpoints are slow or unavailable, a reducer can pay those connection retry costs worker-by-worker before it even starts opening streams.

That means the overall open-stream setup can still be delayed by connection establishment even though the later batch-open RPCs are already parallelized. The slow path becomes most visible when a reducer needs data from multiple workers and one of those workers is slow to accept or establish a data-client connection.

What changes were proposed in this PR?

This PR keeps the existing batch-open protocol, but changes how the reader prepares for it.

Before this change, the reader walked partition locations and immediately created a data client the first time it saw each worker. That meant worker A had to finish client creation before the reader even attempted client creation for worker B, and so on. Only after that serial setup step completed would Celeborn submit the BATCH_OPEN_STREAM requests in parallel.

The new flow first groups pending open-stream locations by worker address. Once that worker-level view is available, the reader creates one data client per distinct worker in parallel using the existing stream creator pool. This keeps concurrency bounded by the same executor that already controls stream-opening work, while removing the unnecessary worker-by-worker wait during client creation.

After client creation completes, the reader builds each worker's BATCH_OPEN_STREAM request only for workers whose data client was created successfully. If one worker fails during client creation, Celeborn preserves the current failed-location exclusion behavior for that worker and still proceeds with healthy workers, so one bad endpoint does not prevent useful setup work from continuing elsewhere.

The tests cover both important behaviors introduced by the refactor: client creation starts concurrently across workers, and a failed worker is skipped without dropping the successful clients created for other workers.

How was this PR tested?

• build/mvn -Pgoogle-mirror,spark-3.3 -pl client-spark/spark-3 spotless:apply
• build/mvn -Pgoogle-mirror,spark-3.5 -pl client-spark/spark-3 -am -DskipTests install
• build/mvn -Pgoogle-mirror,spark-3.5 -pl client-spark/spark-3 -Dtest=CelebornShuffleReaderSuite test