run cargo autoinherit

[zancas]

Motivation

The purpose of this change is to unify redundant dependency information into a Single Source of Truth in the workspace Cargo.toml.

Here's result of a search for a dependency before running the tool:

grep -r -e"color-eyre = \"0.6.3\"" */Cargo.toml
tower-batch-control/Cargo.toml:color-eyre = "0.6.3"
zebra-chain/Cargo.toml:color-eyre = "0.6.3"
zebra-consensus/Cargo.toml:color-eyre = "0.6.3"
zebra-grpc/Cargo.toml:color-eyre = "0.6.3"
zebra-node-services/Cargo.toml:color-eyre = "0.6.3"
zebra-rpc/Cargo.toml:color-eyre = "0.6.3"
zebra-scan/Cargo.toml:color-eyre = "0.6.3"
zebra-state/Cargo.toml:color-eyre = "0.6.3"
zebra-test/Cargo.toml:color-eyre = "0.6.3"
zebra-utils/Cargo.toml:color-eyre = "0.6.3"

The same version information is set in 10 different sources of truth.

After the tool runs the version is specified (uniquely) in the workspace Cargo.toml:

grep -e"color-eyre = " Cargo.toml
color-eyre = { version = "0.6.3", default-features = false }

Specifications & References

https://crates.io/crates/cargo-autoinherit

Solution

cargo autoinherit

Tests

I manually tested by running:

cargo nextest run

PR Author's Checklist

• The PR name will make sense to users.
• The PR provides a CHANGELOG summary.
• The solution is tested.
• The documentation is up to date.
• The PR has a priority label.

PR Reviewer's Checklist

• The PR Author's checklist is complete.
• The PR resolves the issue.

[oxarbitrage]

I think this is a good idea but i want to test it against the Zebra CI so i opened a PR that does the same so we can test that out:

#9041

Also there are a few messages when running cargo autoinherit, they seems fine to ignore as the Cargo.toml of those is actually changed:

`tower-batch-control` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`tower-fallback` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-chain` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-consensus` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-grpc` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-network` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-node-services` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-rpc` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-script` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-state` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-test` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebra-utils` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).
`zebrad` won't be auto-inherited because it appears at least once from a source type that we currently don't support (e.g. private registry, path dependency).

[oxarbitrage]

I replaced this PR with this one #9041 as it can run the CI and we can make updates if needed.