HDDS-16251. Preserve signed empty Content-Type during preprocessing

[F64116045]

What changes were proposed in this pull request?

S3 Gateway's EmptyContentTypeFilter hides an explicitly empty Content-Type to avoid Jersey treating it as a request media type. However, when an S3 client includes the empty header in AWS V4 SignedHeaders, removing it entirely prevents StringToSignProducer from rebuilding the canonical request and the operation fails with InvalidRequest.

This patch preserves the empty value through the existing X-Ozone-Original-Content-Type internal header while continuing to hide Content-Type from Jersey. The existing signature header conversion then restores Content-Type with an empty value for AWS V4 canonical request generation. Unit tests cover both request wrapping and restoration into the signature header map.

This keeps the empty Content-Type workaround introduced for HDDS-4856 while supporting clients that sign the empty header.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-16251

How was this patch tested?

• From the ceph/s3-tests checkout: S3TEST_CONF=<path-to-s3tests.conf> python -m pytest -vv s3tests/functional/test_headers.py::test_object_create_bad_contenttype_empty

CI: https://github.com/F64116045/ozone/actions/runs/32574396997

[F64116045]

The behavior before this change was:

Content-Type: ""
    → EmptyContentTypeFilter removes the header
    → SignedHeaders still contains content-type
    → StringToSignProducer cannot find the signed header
    → InvalidRequest

After this change:

Content-Type: ""
    → EmptyContentTypeFilter preserves it as
      X-Ozone-Original-Content-Type: ""
    → AWSSignatureProcessor restores Content-Type: ""
      in the signature header map
    → StringToSignProducer produces content-type:
    → Signature processing succeeds

[chungen0126]

+1 LGTM