Custom logic for uploading indexes to S3

[odisseus]

The logic of S3Upload mostly replicates s3-upload.kt, but the code is based on Scala futures instead of Kotlin coroutines.

I have tested this implementation manually by uploading indexes for 9 JDKs (61 files total). I have also tested two failure modes (request timeout and incorrect bucket name).

[lukaszwawrzyk]

Make sure that the code is robust:

• we fail fast for obvious error like bucket name is wrong or whatever. Likely all parallel jobs will return quickly with error and that should do it. The error should be clearly visible. We don't want it to hang without output like the original solution.
• introduce some degree of resiliency from infrastructure problems, i.e. if connection drops or we have some timeout on connecting in random file upload or whatever, we should retry configurable number of times, maybe even with some backoff, to ensure that at least we try a few times before failing the whole job.

[odisseus]

It turns out that our S3 client already has some kind of retry functionality (see software.amazon.awssdk.core.internal.http.pipeline.stages.RetryableStage).