chore: bump toolchain to nightly-20251010

[wenym1]

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

What's changed and what's your intention?

Source of code changes:

1. Our forked lru-rs can no longer compiler in the latest toolchain, since it uses Box::into_raw, but in the latest toolchain the method has been disabled for Box with customized Allocator other than Global. Though it's easy to make it compile again, but it seems that the forked crate is only used in bench and rpc_client as a container for client, and therefore we can directly use the official lru-rs.
2. hashbrown 0.14.5 can not cleanly compiled under nightly toolchain without enabling the nightly feature. Previous the feature is enabled via the forked lru-rs. As we are removing the dependency on the forked crate, we should enable the feature in our workspace explicitly.
3. Our previous enabled string_to_string has been deprecated, and the compiler indicates that we should instead enable the superset of it implicit_clone. Most code changes are caused by enabling this lint rule.
4. Removed some explicitly enabled feature that has newly become stable.
5. supress newly generated warning.

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
• chore: bump toolchain to nightly-20251010 #23473 👈 (View in Graphite)
• 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]

What about specifying this in the workspace-config crate?

[wenym1]

Doesn't look like a good idea.

The hashbrown 0.14.5 can only compile in nightly toolchain with its nightly feature is enabled. When doing feature unification to resolve the features enabled in each crate, cargo only include the crate usage when a crate include it in the dependency lists and explicitly use it. Though we have added the hashbrown 0.14.5 in the workspace-config crate, and even have used it with use hashbrown0_14 as _; in the lib.rs, the nightly feature will only be enabled when the crate we are building has included workspace-config in the dependency list. However, the workspace-config is only depended by risingwave_cmd, which means if we build solely on other crates, such as running a test on risingwave_connector, the nightly feature of hashbrown won't be enabled, and then we cannot pass the compile.

To resolve this, we will have to directly or indirectly include workspace-config in all crates that want to be built independently, and the crate risingwave_common is a good common crate that is directly or indirectly depended by most crates. If so, it's better to directly include hashbrown 0.14.5 in risingwave_common, like what we do currently in this PR.

[BugenZhao]

Make sense. This somehow reminds me of the workspace-hack crate. I also encountered this in #23453.

[BugenZhao]

It seems we've stopped using the forked crate and have instead vendorred it directly into our repository since version #16087.

[wenym1]

Yes, we have stopped using it in executor. But as mentioned in the PR description, our rpc_client still use it to hold client, and there is logic of iterating over the lru cache, which is not supported in the one implemented in our repo. This code change is for rpc_client to use the official lru-rs crate.