Fix S3 createExclusive in case of AWS SDK retries

[findepi]

AWS S3 supports S3 conditional writes, which Trino uses to implement
S3OutputFile.createExclusive. AWS SDK also has implicit request
retries in case of certain failures, including read timeouts.

It is possible, as reproduced by TestS3Retries modified in this
commit, that object is created successfully, but AWS SDK is not aware of
that success and retries the request. The retried request then fails
with precondition failure -- from the S3 server side perspective the
object already exists. In fact, in case of single PutObject requests,
there seems to be no way to distinguish requests on the server side.
ETag cannot be used for that, since it's usually content-based.
createExclusive cannot succeed for two different callers even if they
happen to be writing the same key.

What's surprising is that this problem is also present in case of
multi-part upload, at least in MinIO. It's unclear whether AWS SDK
retries combined with multi-part uploads to AWS S3 would also trigger
precondition failure.

The solution for this implemented in this commit is to tag objects
created by Trino with a random value. When precondition fails and AWS
SDK reports that the request was retried (numAttempts > 1), then tags
from the object are checked. FileAlreadyExistsException is raised only
when this request fails, or when the object does not have a tag
indicating it was created by the current thread.

• fixes Exclusive write to a new S3 location may fail with FileAlreadyExistsException #27402

Release notes considerations

Delta Lake

• prevent log writer from failing w/ FileAlreadyExistsException (does not matter when someone used s3.exclusive-create=false configuration)
• writing to s3 now requires permissions for PutObjectTagging and GetObjectTagging operations

[findepi]

CI

• Test TestRedshiftUnloadTypeMapping.testVarbinary is failing #27403 & testVersionOnCompilerFailedError

[pettyjamesm]

The issue makes sense to me, and the approach of using tags to disambiguate should work- but it's worth noting that you do pay for S3 object tags so this does increase the cost profile. How frequently is createExclusive actually called here? Is it for each data file in Iceberg tables or only when updating a single manifest per table / partition?

You mention that eTags can't be used to distinguish between multiple calls to create the same object with the same content- but maybe the other question is: do we actually need to? If we're creating the same object that some other writer created, is it actually necessary to fail in that case? Because if we can tolerate that ambiguity, we could use eTags for this purpose and avoid the cost of using tags.