Add CrtS3TransferManager implementation of upload to support correct progress updates

[alextwoods]

Add CrtS3TransferManager implementation of upload to support correct progress updates.

Motivation and Context

see: #3670

When a non-file source (eg ByteBuffer/bytes[]) is used with the S3TransferManager.upload, the progress reported is inaccurate. This is because the TransferProgressUpdater.wrapRequestBody implementation reports progress when the bytes are read from the body rather than after they are sent on the wire.

Modifications

This PR adds a CRT specific implementation of the upload method that allows us to use the CRT progress listenter - this correctly reports progress on uploads.

Note - this does not address the bug in the Java S3TransferManager - doing so would require significant changes and rework of the ProgressUpdater and requires some mechanism to determine when bytes are actually sent - this likely would require additional event hooks be added to the HTTP client interface.

Testing

New and existing unit and integration tests.

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

[joviegas]

Would it be possible to add an integration test that verifies the progress listener actually reports incremental progress (e.g., 0% → X% → X+Y% → X+Y+Z% → 100%) rather than jumping directly from 0% to 100%?
The unit test confirms the CRT listener is attached, but an integration test could validate the actual progress reporting behavior end-to-end and prevent regression of this issue.

[alextwoods]

Yeah - that's a good idea but might be slightly tricky to get sure it's not flaky - let me see what I can do.

Edit: added a test that is similar to existing tests and should be reliable.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[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.