crypto-common: remove std feature

[tarcieri]

As of #1660, the crypto-common crate stopped linking std entirely by switching to core::error::Error.

That PR didn't remove the std feature however, which was retained to transitively activate the std features of getrandom and rand_core optioinally in the event their corresponding features are enabled.

This PR goes ahead and removes it entirely, which also unblocks being able to remove the std feature from other crates like aead, cipher, digest, and universal-hash.

[newpavlov]

That PR didn't remove the std feature however, which was retained to transitively activate the std features of getrandom and rand_core optioinally in the event their corresponding features are enabled.

I don't think it works like this with the current code. In my understanding, the std feature in aead, cipher, universal-hash will not have such effect.

[tarcieri]

@newpavlov that text is referring to this line here: https://github.com/RustCrypto/traits/pull/1680/files#diff-8c9f78f3e1ed48579936f1e2a5dfc44cd937e3af9aaf4a53ae6fb0f009c81cd1L24

That is the only function of the std feature in the current crypto-common code (prior to this PR).

[newpavlov]

Maybe we can ignore passing std feature to the getrandom and rand_core? Users which need implementation of the Error trait from those crates will be able to enable it explicitly.

[tarcieri]

Sure, that's gone from crypto-common in this PR, and we can remove it in all the other crates that do it as well

[newpavlov]

that test is referring to this line here

But this PR does remove the std feature for crypto-common. Thus IIUC enabling std for aead will not enable it for rand_core.

[newpavlov]

we can remove it in all the other crates that do it as well

Unfortunately, at least for digest we will not be able to do that since it has code which relies on std::io.

[tarcieri]

Yeah, crates that use actual std features like std::io have a reason to retain a std feature