[SPARK-37574][CORE][SHUFFLE] Simplify fetchBlocks w/o retry

[pan3793]

What changes were proposed in this pull request?

Simplify code of fetchBlocks w/o retry

Why are the changes needed?

Simplify code.

The original code added in SPARK-4188, the RetryingBlockTransferor looks quite stable now.

#33340 renames RetryingBlockFetcher to RetryingBlockTransferor, the comment still calls it as Fetcher, it's a little misleading.

if (maxRetries > 0) {
  // Note this Fetcher will correctly handle maxRetries == 0; we avoid it just in case there's
  // a bug in this code. We should remove the if statement once we're sure of the stability.
  new RetryingBlockTransferor(transportConf, blockFetchStarter, blockIds, listener).start()
} else {
  blockFetchStarter.createAndStart(blockIds, listener)
}

Does this PR introduce any user-facing change?

No

How was this patch tested?

Update RetryingBlockTransferorSuite

[AmplabJenkins]

Can one of the admins verify this patch?

[Ngone51]

I wonder how do you prove this since maxRetries default to 3 rather than 0.

[pan3793]

There are several places overwrite the conf to 0, please search ("spark.shuffle.io.maxRetries", "0") in ExternalShuffleIntegrationSuite and BlockManagerSuite

[Ngone51]

When spark.shuffle.io.maxRetries=0, it tests OneForOneBlockFetcher rather than RetryingBlockTransferor, right?

[pan3793]

Sound like add unit test cases in RetryingBlockTransferorSuite is more reasonable, will update soon

[pan3793]

Updated UT, please take a look again.

[github-actions]

We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable.
If you'd like to revive this PR, please reopen it and ask a committer to remove the Stale tag!