fix(core): deserialize duration config values from strings

[subotac]

Which issue does this PR close?

Closes #7887.

Rationale for this change

ConfigDeserializer supplies configuration-map values as strings, but serde's
Duration implementation expects a structured value. As a result, the
default_ttl fields for Redis, Memcached, and Cloudflare KV could not be set
through Operator::via_iter, URI options, or other string-backed configuration.

What changes are included in this PR?

• Add a shared optional-duration deserializer that accepts friendly and ISO-8601
  strings through the existing signed_to_duration() parser.
• Preserve support for the structured serde representation and keep the public
  Option<Duration> fields and builder APIs unchanged.
• Apply the helper to all three affected services and document their accepted
  string formats.
• Add regression coverage for friendly, fractional, and ISO-8601 durations,
  structured input, and rejection of a unitless duration.

Validation:

• cargo test -p opendal-core -p opendal-service-redis -p opendal-service-memcached -p opendal-service-cloudflare-kv
• cargo clippy -p opendal-core -p opendal-service-redis -p opendal-service-memcached -p opendal-service-cloudflare-kv --all-targets --all-features -- -D warnings
• cargo +1.91.0 clippy -p opendal-core -p opendal-service-redis -p opendal-service-memcached -p opendal-service-cloudflare-kv --all-targets --all-features -- -D warnings
• cargo doc -p opendal-core -p opendal-service-redis -p opendal-service-memcached -p opendal-service-cloudflare-kv --lib --no-deps --all-features
• python scripts/workspace.py cargo fmt -- --check

Are there any user-facing changes?

Yes. String-backed configuration can now set the three default_ttl fields
with explicit-unit friendly values such as 5s and 1500ms, or ISO-8601 values
such as PT1M. Unitless values remain invalid.

AI Usage Statement

AI assisted with analysis and testing.

[tisonkun]

jiff's SignedDuration should accept "friendly format" already and the comment may not applied to other bindings.

• https://docs.rs/jiff/latest/jiff/fmt/friendly/index.html

impl core::str::FromStr for SignedDuration {
    type Err = Error;

    #[inline]
    fn from_str(string: &str) -> Result<SignedDuration, Error> {
        parse_iso_or_friendly(string.as_bytes())
    }
}

[tisonkun]

@subotac could you elaborate why jiff's friendly parser not enough?

[subotac]

@subotacЧи не могли б ви пояснити, чому дружнього парсера Jiff недостатньо?

The jiff friendly parser is sufficient for parsing the value, and this patch already uses it through signed_to_duration().

The missing part is the serde bridge: ConfigDeserializer provides "5s" as a string, while std::time::Duration's Deserialize implementation expects the structured { secs, nanos }
representation and does not invoke jiff or FromStr.

deserialize_option_duration only routes string-backed configuration through the existing jiff parser and converts the resulting SignedDuration to std::time::Duration. It alsso preserves
compatibility with structured serde input

The internal enum could use SignedDuration directly instead of String and rely on jiff's serde implementation, but an adapter and conversion to std::time::Duration would still be required

[tisonkun]

Thanks! I wonder if we can use jiff::SignedDuration in those service places and convert jiff::SignedDuration to std Duration when it is necessary (perhaps we would find jiff::SignedDuration provides even better interface)

• https://docs.rs/jiff/latest/jiff/struct.SignedDuration.html#method.unsigned_abs

[subotac]

Thanks! I wonder if we can use jiff::SignedDuration in those service places and convert jiff::SignedDuration to std Duration when it is necessary (perhaps we would find jiff::SignedDuration provides even better interface)

• https://docs.rs/jiff/latest/jiff/struct.SignedDuration.html#method.unsigned_abs

Yes, that direction can work. I checked the three service configs and there are two compatibility details to account for:

• the config structs are public, and the binding generator currently classifies duration fields by the Rust type name Duration, so changing them to SignedDuration also requires updating the generator mapping andt
  changes the public Rust config field type;
• I would prefer std::time::Duration::try_from(value) at build time instead of unsigned_abs(), so negative TTL values are rejected rather than silently converted to positive values.

If that tradeoff is acceptable i can rework the three config fields to use SignedDuration, keep the builder methods accepting std::time::Duration, update the binding generator classification, and convert once in
each service builder

[tisonkun]

@subotac your analyze makes sense. Please go ahead!

[subotac]

@tisonkun Thanks for the guidance. The agreed SignedDuration-based implementation is now complete in fed4f0e5: the affected service configs store SignedDuration, the builder API remains on std::time::Duration, negative TTL values are rejected, and the generator handles both duration types. The affected tests, parser tests, formatting, generator checks, and core/dev Clippy checks all pass.

This should address the requested changes. Could you please take another look when you have a chance? If there are additional improvements beyond the scope of this issue, I would be happy to handle them separately.

[tisonkun]

Thanks for your contribution @subotac!

LGTM.

[tisonkun]

As a follow up I actually think we can investiagte the usage of this method and port all of them to signed_duration_to_duration. This makes all XxxConfig use a typed struct rather than ttl: Option<String> and relying on the implicit contract.

[tisonkun]

I'm holding on merging this PR for next minor release. I would prevent this minor API change in a patch release.

Sorry I just see this comment.

[tisonkun]

You can sent a revert commit and resubmit it later. I'm sorry.

[erickguan]

@tisonkun It's fine. I saw you merged the PR. I will track this in the upcoming release issue.

[tisonkun]

Thanks!