Propagate content-type from AsyncRequestBody for multipart uploads (Issue #6607)

[joviegas]

Motivation and Context

When uploading files using S3AsyncClient with multipartEnabled(true), the content-type from AsyncRequestBody (e.g., text/html for .html files) was ignored. Instead, multipart uploads always used the default binary/octet-stream. This caused files to be stored with incorrect content-type in S3. Fixes #6607.

Modifications

• Added content-type enrichment in UploadObjectHelper.uploadObject() to propagate content-type from AsyncRequestBody to PutObjectRequest
  before multipart upload.

Before this fix:

• Single-part uploads correctly used the content-type from AsyncRequestBody (e.g., text/html for .html files)
• Multipart uploads ignored AsyncRequestBody.contentType() and always defaulted to binary/octet-stream

After this fix:

• Both single-part and multipart uploads now consistently use the content-type from AsyncRequestBody

Testing

• Added unit tests in UploadObjectHelperTest and UploadWithUnknownContentLengthHelperTest
• Added WireMock functional tests in S3MultipartClientContentTypeTest verifying content-type propagation for both single-part and
  multipart uploads
• All existing S3 and Transfer Manager tests pass

Types of changes

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

License

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

[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