refactor(storage): use new higher rank lifetime assumption to avoid unnecessary clone

[wenym1]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Add an experimental rustc flag "-Zhigher-ranked-assumptions" to bypass the false positive borrow checker error discussed in rust-lang/rust#100013. The rustc flag is recently enabled after rust-lang/rust#143545 gets merged to the rust toolchain.

After enabling this rustc flag, for the on_key_value and nearest state store trait method, which pass a closure to observe the slice value, the closure does not have to be static, and in the method caller, we can avoid unnecessary clone to make the closure static.

Checklist

• I have written necessary rustdoc comments.
• I have added necessary unit tests and integration tests.
• I have added test labels as necessary.
• I have added fuzzing tests or opened an issue to track them.
• My PR contains breaking changes.
• My PR changes performance-critical code, so I will run (micro) benchmarks and present the results.
• I have checked the Release Timeline and Currently Supported Versions to determine which release branches I need to cherry-pick this PR into.

Documentation

• My PR needs documentation updates.

Release note

[wenym1]

• refactor(storage): use new higher rank lifetime assumption to avoid unnecessary clone #23490 👈 (View in Graphite)
• chore: bump toolchain to nightly-20251010 #23473
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[graphite-app]

Looks like this PR extends new SQL syntax or updates existing ones. Make sure that:

• Test cases about the new/updated syntax are added in src/sqlparser/tests/testdata. Especially, double check the formatted_sql is still a valid SQL #20713
• The meaning of each enum variant is documented in PR description. Additionally, document what it means when each optional clause is omitted.

[BugenZhao]

LGTM!

[BugenZhao]

Shall we by default to also set -Dwarnings in config.toml?

[wenym1]

I don't think this is a good idea. -Dwarnings is used here because we want to quickly detect the warning and return with error in CI, but not a general requirement when we build the doc.