[Cargo.toml] update rand to 0.7 (breaking change)

[niklasad1]

Needed by openethereum/parity-ethereum#11022

[parity-cla-bot]

It looks like @niklasad1 signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[dvdplm]

@niklasad1 @ordian is this a good time to update our fork with the upstream changes?

[ordian]

@dvdplm our fork has diverged a bit rust-bitcoin/rust-secp256k1@master...paritytech:master, so it could be quite involved, but we need to do this for sure.

[dvdplm]

so it could be quite involved, but we need to do this for sure.

Has a stab at this. It's a bit fiddly but not too bad tbh. I'll hold off until @grbIzl is done with his work on ethkey.

[niklasad1]

@dvdplm @ordian can we merge this?

[dvdplm]

@niklasad1 there was some talk over on the dalek lib to skip 0.7 altogether (apparently a very minor change not worthy of a semver-minor bump). I honestly don't know why not upgrade (or conversely what the reasons are to upgrade).

Can you explain why we want to upgrade? Maybe you did already but I have goldfish memory... ;)

[dvdplm]

Can you explain why we want to upgrade? Maybe you did already but I have goldfish memory... ;)

Nvm, ignore me. We've already made the decision to go with 0.7 when we merged the PR in parity-common.

[niklasad1]

Yes, after openethereum/parity-ethereum#11139 lands it could make sense to merge this and use rand 0.7. However, I'm not sure if use this crate somewhere else than in parity-ethereum.

[dvdplm]

I'm not sure if use this crate somewhere else than in parity-ethereum.

rust-libp2p uses upstream (https://github.com/rust-bitcoin/rust-secp256k1/) and substrate uses https://github.com/sorpaas/libsecp256k1-rs so I think parity-ethereum is the only one.

[dvdplm]

Looks like CI needs a kick in the butt here. :/

[niklasad1]

I changed the trait bounds in the tests after you approved it, ok to merge?