HDDS-15515. Support object Content-Type end-to-end in S3 Gateway

[rich7420]

What changes were proposed in this pull request?

The S3 Gateway never persisted an object's Content-Type. The request
Content-Type was only forwarded to HeaderPreprocessor for SigV4 signing
(X-Ozone-Original-Content-Type) and was never stored in the OM key metadata;
GetObject did not set it from the object and HeadObject hard-coded
binary/octet-stream. Because the value is never stored, CopyObject /
UploadPartCopy cannot preserve or replace it, so copied (and plain) objects
consistently default to octet-stream.

This is an end-to-end gap, not a copy-only issue. This PR adds object
Content-Type support across the read/write/copy paths, aligning with AWS S3:

• PutObject / CreateMultipartUpload — store the request Content-Type in
  the OM key metadata, mirroring the existing ETag-in-metadata convention.
• GetObject / HeadObject — return the stored Content-Type, defaulting to
  binary/octet-stream when absent (the response-content-type query
  parameter still overrides).
• CopyObject metadata directive — COPY (default) preserves the source
  object's Content-Type (it rides along in the copied source metadata);
  REPLACE applies the Content-Type from the copy request.
• A user-supplied x-amz-meta-content-type is remapped to a dedicated key so
  it does not collide with the object's stored Content-Type. The reserved-key
  remap/rebuild that previously existed only for ETag is now factored into a
  shared helper and reused for both.

Before vs after (response):

Path	Before	After
PUT/MPU	Content-Type not persisted	stored in key metadata
GET	only set from request header / response-content-type	falls back to stored Content-Type
HEAD	hard-coded binary/octet-stream	stored Content-Type (or default)
COPY (COPY)	dest defaults to octet-stream	keeps source Content-Type
COPY (REPLACE)	dest defaults to octet-stream	uses request Content-Type

What is the link to the Apache JIRA

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

How was this patch tested?

https://github.com/rich7420/ozone/actions/runs/27210927693

[rich7420]

Cc @peterxcli

[Gargi-jais11]

Thanks @rich7420 for finding out the issue. I got similar root cause for test case failure in MINT test. Didn't know about your patch, I have marked my jira as duplicate https://issues.apache.org/jira/browse/HDDS-15591. Will review the patch.

Test failure : Mint aws-sdk-go-v2 / testBasicObjectOperations

[rich7420]

no problem, thanks @Gargi-jais11 to mention that

[Gargi-jais11]

Add a testcase to TestObjectHead for x-amz-meta-content-type-
One end-to-end PUT + HEAD test coverage for write remap, read rebuild, and separation of system vs user metadata:
To test user Content Type metadata does not collide with object ContentType.

[rich7420]

@Gargi-jais11 thanks for your comments!

[chungen0126]

+1 LGTM

[Gargi-jais11]

Thanks @rich7420 for updating the PR. LGTM! , +1.

[rich7420]

@Gargi-jais11 and @chungen0126
thanks for the review!