Replace S3 downloadInParallel by using Content-Range requests instead of undocumented S3 part requests

[ffeldhaus]

As stated in #1172 AWS SDK for Java currently uses an undocumented S3 functionality to parallelize downloads using part requests instead of using the documented Content-Range requests as AWS SDK for Ruby and Python do.

There are two advantages for changing the current behaviour:

1. Using Content-Range requests is much more flexible as the client can use arbitrary part sizes for downloads instead of the predefined part sizes which were created when the object was uploaded. This can potentially speed up the transfer by using more parts than during upload or a different part size. Also the initial HEAD request to retrieve the number of parts will not be necessary, speeding up the time to start the download and thus reducing time to first byte latency.
2. AWS SDK for Java would use officially documented S3 functionality instead of undocumented functionality which will reduce issues with S3 compatible solutions

[shorea]

This sounds like a good suggestion @ffeldhaus, I'll discuss with the team to see if that's the direction we want to take.

[ffeldhaus]

@shorea do you have a decision in this topic? I‘d be glad to contribute the code via a pull request.

[akash18]

Any updates on this issue?

[debora-ito]

@ffeldhaus @akash18

The SDK team has reviewed the feature request list for V1 and decided not to make this change, as they are concentrating efforts on V2 new features. It will be considered for the TransferManager refactor in V2, see the referenced issue above. I'll go ahead and close this.

Please feel free to comment on the V2 issue with your use case, and reach out if you have further questions.