Remove EmptyObjectRangeNotSatisfiableException, add presigned URL Javadoc and checksum test

[jencymaryjoseph]

Motivation and Context

Cleans up the 416 fallback mechanism, documents presigned URL limitations, and adds data-integrity regression testing.

1. 416 cleanup: When a presigned URL multipart download sends a ranged GET to an object that has been replaced with an empty object (0 bytes), S3 returns HTTP 416 (Range Not Satisfiable). The SDK handles this by falling back to a non-ranged GET.
   The parallel subscriber wrapped this 416 in EmptyObjectRangeNotSatisfiableException so the catch in PresignedUrlDownloadHelper could distinguish it from other errors and trigger the fallback. Since isRangeNotSatisfiable() already detects raw 416s from any path (parallel or serial), the wrapper is redundant, removing it simplifies the error handling to a single check.The parallel subscriber wrapped 416 errors in EmptyObjectRangeNotSatisfiableException so the fallback catch could identify them. Since isRangeNotSatisfiable() already detects raw 416s from any path, the wrapper is redundant, removing it simplifies the error handling.

2. Javadoc: Customers have no documentation on which signed headers are supported for presigned URL downloads. Without it, they'll hit SignatureDoesNotMatch errors with no guidance on what went wrong.
   When a presigned URL is generated with header-location fields (like Range, If-Match, SSE-C headers etc.), those headers get signed into the URL. At download time, the SDK needs to replay them, as the URL will not have the header values. But we currently only support replaying Range and If-Match (via the builder methods) and x-amz-checksum-mode (automatically by the SDK). Any other signed headers can't be replayed, causing S3 to reject the request with SignatureDoesNotMatch. The Javadoc makes this clear so customers know upfront which presigned URL configurations are supported.

3. Checksum regression test: Added integration tests validating that downloaded bytes via presigned URLs match the uploaded content. This test proves data integrity across client types, object sizes, and transformer types.

Modifications

• PresignedUrlDownloadHelper: Simplified 416 catch to isRangeNotSatisfiable(cause) only. Deleted EmptyObjectRangeNotSatisfiableException.
• PresignedUrlMultipartDownloaderSubscriber / ParallelPresignedUrlMultipartDownloaderSubscriber: Pass raw error directly instead of wrapping.
• PresignedUrlDownloadRequest: Added Javadoc documenting that presigned URLs with signed headers beyond Range, If-Match, and x-amz-checksum-mode are not supported. x-amz-checksum-mode is replayed automatically by the SDK.
• PresignedUrlDownloadRegressionTesting: New regression test validating CRC32(downloaded) == CRC32(uploaded) across single-part and multipart clients, multiple sizes (empty, 16KB, 27MB, MPU), all transformer types (toBytes, toFile, custom), and range requests.

Testing

• Existing tests pass (PresignedUrlMultipartDownloaderSubscriberWiremockTest, PresignedUrlDownloadHelperTest)
• New regression test: 13 parameterized cases, all passing

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.