chore: workspace inheritance

[yihau]

workspace.package

• Cargo.toml
• programs/sbf/Cargo.toml

workspace.dependencies

• Cargo.toml
• programs/sbf/Cargo.toml

btw, I merge some dependencies's version. if A use foo = "1" and B use foo = "1.10.1", I move foo = "1.10.1" to workspace and both A and B inherit it.
there are some dependencies's version are different. I will make other PRs to union them.

scripts

• get version from root Cargo.toml
• increasing cargo version for root Cargo.toml as well
• ignore some checking when version = { workspace = true }

[steviez]

Thanks for doing this! I took a crack at this a few months ago, but ran into a CI issue that held things up before the PR fell off my radar. Nice to have a single point to change on all these deps, definitely simplifies operations that need to be done manually / shrinks diffs from running scripts.

A question from the old review that came up that I'll post here in case anyone else might have the same question:

On cargo publish, does cargo do the right thing and rewrite the Cargo.toml to not depend on the workspace file?

The answer is yes, and I confirmed it by running the following and inspecting the generated Cargo.toml file.

$ cargo publish --dry-run --package solana-logger

[willhickey]

Do you plan on backporting this to v1.14? I'm running some tests (all good so far) but my attempt to cherry pick to v1.14 ran into a bunch of trivial conflicts. Just wondering if I should take the time to test on v1.14.

[mvines]

No 1.14 backport please, too much churn for a stable branch

[yihau]

downstream project failed due to https://www.github.com/hyperium/hyper/issues/3045
I'm thinking upgrade hyper 0.14.20 => 0.14.23 and socket2 0.4.4 => 0.4.7 to solve the issue.

[steviez]

I'm thinking upgrade hyper 0.4.20 => 0.4.23 and socket2 0.4.4 => 0.4.7 to solve the issue.

Seems reasonable to me; think it makes sense to do those bumps in separate PR's like the other dependency bump PR's I see you've opened recently

[steviez]

This is a large diff so not going to pretend I went through every line. Instead, the checks I performed:

• Ran cargo tree on current tip of master and the PR branch and compared output; there was no difference
• When I took a crack at this a while back, I tested a concern Michael had about the correct version getting populated in individual crates. I had tested that and tested again with no issue.
  • I tested by running cargo publish --dry-run --package solana-logger and inspecting /target/package/solana-logger-1.15.0/Cargo.toml

[t-nelson]

This is a large diff so not going to pretend I went through every line. Instead, the checks I performed:

• Ran cargo tree on current tip of master and the PR branch and compared output; there was no difference
• When I took a crack at this a while back, I tested a concern Michael had about the correct version getting populated in individual crates. I had tested that and tested again with no issue.
  • I tested by running cargo publish --dry-run --package solana-logger and inspecting /target/package/solana-logger-1.15.0/Cargo.toml

seems sufficiently rigorous to me!

[mergify]

⚠️ The sha of the head commit of this PR conflicts with #29893. Mergify cannot evaluate rules on this PR. ⚠️