[feature](s3) Support S3 Express One Zone

[0AyanamiRei]

What problem does this PR solve?

Issue Number: None

Related PR: #63409

Problem Summary:

Doris can use the existing S3 import pipeline to read object data from Amazon S3 Express One Zone, but it must first recognize a directory bucket and create an AWS SDK client with S3 Express endpoint rules and session authentication enabled. The previous implementation also inferred S3 Express from user-provided endpoints and changed shared import/storage abstractions. This PR narrows the feature to S3 Express semantics required by the import layer.

This PR supports S3 Express reads only for:

• Non-internal one-shot INSERT INTO ... SELECT ... FROM S3(...).
• Broker Load using WITH S3.

After file discovery, both paths continue through the existing S3 import flow for exact paths, multiple paths, globs, format parsing, schema inference, column mapping, Range GET, and load execution.

Directory bucket, endpoint, and Region contract

An S3 Express directory bucket must be supplied as the complete bucket name embedded in the URI:

<bucket-base-name>--<zone-id>--x-s3

For example:

bucket-name--usw2-az1--x-s3

S3 Express mode is selected only when all of the following are true:

• The statement is one of the two supported import entry points.
• s3.provider is explicitly set to AWS.
• The URI contains a valid complete directory bucket name.

The complete directory bucket name is the source of truth. To avoid bucket Zone/Region and bucket Zone/endpoint Zone mismatches, users are recommended to provide the complete bucket name and omit both s3.endpoint and s3.region.

Doris enables AWS SDK automatic endpoint and S3 Express session-authentication behavior:

• A user-provided s3.endpoint is not used as endpointOverride; the SDK derives the zonal data endpoint from the complete directory bucket name.
• Doris does not validate bucket Zone against configured Region, bucket Zone against endpoint Zone, or endpoint against configured Region. If endpoint or Region is supplied, no mismatch check is performed.
• For currently known Zone prefixes, Doris derives the full Region from the bucket name, for example usw2-az1 to us-west-2. This derived Region takes precedence over a user-provided Region.
• If AWS introduces a Region whose Zone prefix cannot yet be expanded by Doris, Doris uses the user-provided s3.region unchanged as the SDK Region, without consistency validation. If neither inference nor a fallback Region is available, the request fails with a clear error.
• S3 Express always uses HTTPS and virtual-hosted-style addressing. A supplied use_path_style value is still validated as a boolean, but the Express client does not propagate a path-style preference and always uses virtual-hosted style.
• The configured AWS credentials are base credentials. The AWS SDK automatically calls CreateSession, caches the S3 Express session credentials, and refreshes them when needed.

Recommended usage:

FROM S3(
    "uri" = "s3://bucket-name--usw2-az1--x-s3/import/**/part-*.parquet",
    "s3.provider" = "AWS",
    "s3.access_key" = "<access-key>",
    "s3.secret_key" = "<secret-key>",
    "use_path_style" = "false", -- use virtual-hosted style
    "format" = "parquet"
);

See the AWS documentation for S3 Express SDK session authentication and directory bucket endpoints and Zone IDs.

Implementation scope

• FE attaches an internal marker only to the two supported import paths. Raw user property maps cannot enable the marker.
• FE uses an SDK-managed Express client only for directory-bucket ListObjectsV2 discovery. It follows directory-bucket listing constraints by using slash-terminated prefixes and continuation-token pagination without StartAfter.
• BE recognizes the same complete bucket-name format, resolves the effective Region, ignores endpoint override, forces HTTPS/virtual-hosted style, and lets the AWS C++ SDK select the S3 Express signer and session credential provider. Object reads then use the existing S3 read implementation.
• Ordinary S3 buckets and S3-compatible services retain their existing endpoint, Region, addressing, and client behavior.

This PR does not add S3 Express support to standalone S3/FILE TVF queries, CTAS, INSERT OVERWRITE, COPY, Streaming Insert, internal loads, external catalogs, resources, storage vaults, Doris internal storage, export, upload, multipart upload, delete, rename, checksum handling, or other write paths.

Release note

Support importing data from existing Amazon S3 Express One Zone directory buckets through one-shot INSERT INTO ... SELECT ... FROM S3(...) and Broker Load WITH S3.

Check List (For Author)

• Test

  • Regression test
  • Unit Test
    • FE core targeted unit tests: 58 passed.
    • FE filesystem targeted unit tests: 138 passed.
    • BE targeted S3ClientFactoryTest: 12 passed.
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.
    • Only the two scoped S3 import entry points select SDK-managed S3 Express endpoint and session authentication.
    • User endpoint is ignored; known bucket Zone prefixes determine Region, and user Region is only an unchecked fallback for unknown prefixes.
    • Non-target entry points, ordinary S3 behavior, and S3 write behavior remain unchanged.

• Does this need documentation?

  • No.
  • Yes. A follow-up documentation PR will describe the supported import entry points and configuration contract.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?