feat(storage/opendal): route oss:// URLs through the S3 backend

[plusplusjiajia]

Which issue does this PR close?

N/A

What changes are included in this PR?

Aliyun OSS exposes an S3-compatible API, and the other two Iceberg implementations already read oss:// tables through their S3 code path with canonical s3.* properties:

• pyiceberg: constructs a pyarrow.fs.S3FileSystem for oss:// locations.
• Java S3FileIO: accepts any URI scheme by design — the scheme is a label, transport is always the AWS S3 SDK.

iceberg-rust routes oss:// to opendal's native Oss service instead, which reads a separate oss.* namespace and can't be driven by the same credentials. Align with the rest of the ecosystem.

[CTTY]

Hi @plusplusjiajia thanks for the contribution! Logic wise this makes sense, but I'm concerned that this will confuse users that OSS storage has two modes. Do you think we should just keep one?

[CTTY]

Suggested change

	#[cfg(feature = "opendal-s3")]
	#[cfg(all(feature = "opendal-oss", feature = "opendal-s3"))]

Only having s3 feature flag will introduce oss related code to non-oss users

[plusplusjiajia]

@CTTY Fixed.

[CTTY]

I'm not very familiar with OSS storage so not sure about it: Is the fallback actually necessary? I'm thinking if using OSS exactly like S3 is the common case, maybe we can just use OpenDalS3Storage directly?

[plusplusjiajia]

@CTTY Agreed, removed it. OSS is S3-compatible and the Java/Python Iceberg implementations both route OSS through S3FileIO without a native fallback.

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[Xuanwo]

iceberg-rust routes oss:// to opendal's native Oss service instead, which reads a separate oss.* namespace and can't be driven by the same credentials. Align with the rest of the ecosystem.

Instead of trying to route OSS to S3, I suggest allowing OSS to parse options from the S3 config.

OpenDAL's OSS support is natively implemented, which means it works with Aliyun OSS's RAM out of the box. Switching to S3 services prevents users from working with Aliyun's OIDC or assume roles.

[plusplusjiajia]

Hi @plusplusjiajia thanks for the contribution! Logic wise this makes sense, but I'm concerned that this will confuse users that OSS storage has two modes. Do you think we should just keep one?

Good point. I've removed the native OSS fallback entirely — OSS now only routes through S3, matching what pyiceberg does (apache/iceberg-python#1392).