Evenly distribute exchange spooling data across different shards

[linzebing]

Description

Is this change a fix, improvement, new feature, refactoring, or other?

Improvement.

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

trino-exchange

How would you describe this change to a non-technical end user or system administrator?

Sometimes we run into cases where we get throttled by S3.

1. Supporting multiple buckets as exchange spooling destinations will distribute the requests to get around the throttling limits. Currently, data of different taskPartitions gets assigned to these buckets in a round-robin fashion.
2. Adding a random prefix to sink output path. Data output file path format: {randomizedPrefix}.{queryId}.{stageId}.{sinkPartitionId}/{attemptId}/{sourcePartitionId}_{splitId}.data

Related issues, pull requests, and links

Documentation

() No documentation is needed.
(x) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[arhimondr]

LGTM % comments

[losipiuk]

nit: passing i as taskPartitionId is somewhat ugly, and exploits the implementation details of getExchangeDirectory (that it uses partitionId modulo number of base directories to determine final directory shape).
A cleaner approach would be to have explicitly method List<URI> getAllExchangeDirectories() and use it in close and in initialize

[linzebing]

With the last commit, this part has been changed to delete all task output directories. I will create a follow up PR to delete the directories in batches.