Switch Cargo.toml in packages to use workspace dependencies

[carver]

What was wrong?

Fix #845

How was it fixed?

My process:

• Copied the version definitions into the workspace Cargo.toml and referred to them from each package
• If multiple versions are used in different packages, specify the highest version to use in the workspace
• If different features are used in different packages, specify the minimal subset in the workspace, and add features as needed in each package

There are several dependencies that are only used in a single package. I can see arguments for moving them to the workspace for tracking too. For example, if we don't move the dependencies, then it will be easy to accidentally create duplicates again in the future. But I landed on leaving them in place, because:

1. It highlights that removing a singular dependency from a package will completely remove it from the whole workspace
2. It feels a tiny bit burdensome to add every future dependency to the workspace when it's only in use in one place. So I wasn't ready to pick that as the new norm

But I'm open to persuasive arguments :)

To-Do

• [x] root
• [x] e2store
• [x] ethportal-api
• [x] ethportal-peertest
• [x] light-client
• [x] portal-bridge
• [x] portalnet
• [x] rpc
• [x] trin-beacon
• [x] trin-execution
• [x] trin-history
• [x] trin-metrics
• [x] trin-state
• [x] trin-storage
• [x] trin-utils
• [x] trin-validation
• [x] utp-testing
• [x] Clean up commit history and use conventional commits.
• [x] Follow-up task writeups
  • [x] Move dependency repositories to ethereum org
  • [x] ssz unification?

[carver]

Since Cargo.lock wasn't updated, does that mean that there was no dependency that was used with different version?

Yeah, I think because of the regular updates, like this one, most of the locked dependencies were further ahead of any of the Cargo.toml specs anyway.

Somewhat related, should we create issue(s) for

Sure, I'll take a stab at writing some up 👍🏻