feat(services): support if_match conditional writes for azblob and gcs

[shanielh]

Which issue does this PR close?

Closes #7889

Rationale for this change

Conditional-write support (if_match / if_none_match) was inconsistent across object-storage services: S3 supported if_match but not arbitrary-ETag if_none_match (a genuine AWS API limitation — S3's x-amz-if-none-match only accepts the literal *), Azure Blob supported if_none_match but not if_match, and GCS supported neither for writes. This PR closes the two gaps that are actually fixable given each provider's API (Azure's if_match, GCS's generation-based conditional writes), while leaving S3 as-is since its gap is not implementable through the S3 API.

What changes are included in this PR?

• Azure Blob: added write_with_if_match capability and wired the If-Match header into azblob_put_blob_request, mirroring the existing if_none_match handling.
• GCS: added write_with_if_match and write_with_if_none_match capabilities. GCS's JSON API has no ETag-based conditional write mechanism, only generation-number query params, so these are implemented on top of ifGenerationMatch / ifGenerationNotMatch. The object generation number is exposed via the existing Metadata::version() field (already populated by GCS's stat/read/list paths), so no new Metadata fields were needed. Non-numeric if_match/if_none_match values return an Unsupported error.
• Capability docs: documented in core/core/src/types/capability.rs that GCS repurposes if_match/if_none_match to carry a generation number rather than a literal ETag; added a corresponding note to GCS's docs.md.
• Behavior tests: updated the shared test_write_with_if_match / test_write_with_if_none_match tests (core/tests/behavior/async_write.rs) to use the object's generation (Metadata::version()) as the match token for GCS and its ETag for all other backends, since enabling the new capability flags makes these shared tests exercise GCS for the first time.
• No changes to S3.

Are there any user-facing changes?

Yes:

• Azure Blob users can now pass if_match to write_with, matching the behavior already available for if_none_match.
• GCS users can now pass if_match / if_none_match to write_with for optimistic-concurrency writes, but must pass the object's generation number (from Metadata::version()), not a literal ETag — this is called out in the capability doc comments and GCS's docs.md.

AI Usage Statement

This PR was developed with Claude Code (Anthropic), model Claude Sonnet 5, including codebase investigation, implementation, and verification (cargo fmt, cargo clippy -D warnings, cargo check --all-features, doc tests). Live behavior tests against real GCS/Azure backends were not run — no credentials were available in the development environment.

[Xuanwo]

Thank you for working on this.

The azure part seems good to me, but I strongly againest the gcs change.

[Xuanwo]

No, we don't do this. It's very clear that if-match accepts an etag.

---

Think about this, we now have a user want to support all of s3, azblob and gcs.

The user is using APIs like:

let expected_etag = op.stat(pathx).await?.etag();
let _ = op.write_with(pathx, data).if_match(expected_etag).await?;

Then this user will go crazy to find that it doesn't work on gcs, because if_match always didn't match the give etag. After reading docs, they realized that they need to do:

let expected_etag = if op.scheme() == "gcs" {
    op.stat(pathx).await?.version()
} else {
    op.stat(pathx).await?.etag()
};

let _ = op.write_with(pathx, data).if_match(expected_etag).await?;

I don't think they will love opendal again.

[Xuanwo]

The same.

[Xuanwo]

Please don't declare a feature that services didn't support.

[shanielh]

@Xuanwo maybe we should add a new capability for write if version match? I believe the write if none is fine for GCS.

If so. I'll be happy to implement it for GCS.