update most of the dependencies

[ordian]

The update was done via cargo upgrade --workspace and then a couple of updates were reverted:

• bitvec requires update from parity-scale-codec
• shared_memory update is more involved (seems to be split into https://github.com/elast0ny/raw_sync-rs)
• tokio 0.3 was reverted to 0.2, require update from substrate

• tiny-keccak was updated manually

as mentioned in paritytech/substrate#7509 (comment), it would be nice to do a burnin.

[ordian]

Haven't noticed any anomalies in the metrics.

[mxinden]

Thanks for doing this @ordian!

For what my review is worth, the changes look good to me, apart from the question below. Given my low involvement in the Polkadot code base and the size of this change, I would very much appreciate more eyes on this pull request.

Haven't noticed any anomalies in the metrics.

Same here. This has been running on a sentry node (kusama-sentry-ew4-0) for more than 5 days. Before merging, I would recommend running it on a validator as well. What do you think @ordian?

[mxinden]

If I understand package correctly, one can use it to rename dependencies. Why is it needed here, given that it does not rename the import variable, but instead just repeats the name?

[ordian]

This was a bug in cargo-edit tool that I used to automatically bump all the dependencies. Reverted this change manually for futures in 3d16db4, thanks for catching this for parity-scale-codec, will fix now.

[tomaka]

There's indeed a lot of these package = "...", notably for futures and parity-scale-codec.

LGTM once these are removed.
I'm neutral about the question of whether to test it on a validator as well.

[ordian]

Addressed the renaming for parity-scale-codec and the remaining for futures.

Note that this PR doesn't upgrade dependencies constrained by sub-dependencies, like libp2p (constrained by substrate) or bitvec (by parity-scale-codec). Once we upgrade dependencies in substrate, there might be a new bunch to upgrade here.

[ordian]

Before merging, I would recommend running it on a validator as well. What do you think @ordian?

I don't think a validator burn-in is necessary here, but don't have a strong opinion either.

[mxinden]

For what my review is worth, this looks good to me.