kem: remove tests, update to rand_core v0.9

[newpavlov]

As discussed here the tests are not particularity useful and block migration to rand_core v0.9.

cc @rozbb

[newpavlov]

Here I used CryptoRng instead of TryCryptoRng since it's not clear how implementers should deal with potential RNG errors.

One option is to define two separate methods:

// Find a better name?
pub enum EncRngError<EncErr, RngErr> {
    // Encapsulation error
    Enc(EncErr),
    // RNG error
    Rng(RngErr),
}

pub trait Encapsulate<EK, SS> {
    type Error: Debug;

    fn encapsulate<R: CryptoRng>(&self, rng: &mut R) -> Result<(EK, SS), Self::Error> {
        self.encapsulate_with_try_rng(rng).map_err(|EncRngError::Enc(err)| err)
    }
    // Find a better name?
    fn encapsulate_with_try_rng<R: TryCryptoRng>(
        &self,
        rng: &mut R,
    ) -> Result<(EK, SS), EncRngError<Self::Error, R::Error>>;
}

But I think it's better to do it in a separate PR.

[rozbb]

Is there a detailed discussion for why TryCryptoRng is necessary? In the failure modes I’m imagining (finicky external hardware), the solution would be to just poll the hardware to get 32B and then seed a Chacha12Rng. It’d be nice to not support Try*

[newpavlov]

It's primarily to support IO-based RNGs like OsRng (i.e. "to just poll hardware" in your comment) and to replace potential (albeit highly unlikely in practice) panic branches with explicit error processing. If you do not want to deal with this, you always can use the UnwrapErr wrapper.