Upgrade to rand 0.10

[djc]

There are some pain points here:

• More fallibility: using SysRng to initialize has become explicitly fallible, which is fair enough but then requires some of our APIs to be fallible as well (or panicking, I suppose?). This affects Endpoint::new() and Bbr::new(); the latter in turn wants to infect the ControllerFactory::build() method.
• StdRng is no longer Clone which is also fair enough, but right now our Controller trait has a clone_box() method which we use for path migration (as well as to expose the congestion controller state via quinn::Connection::congestion_state()).

[Ralith]

More fallibility

Maybe passing some entropy down explicitly could help with at least the controller side of things? Similar to how we plumb through RNG seeds. We could even make EndpointConfig::rng_seed a required argument, but that's probably too user-hostile.

right now our Controller trait has a clone_box() method

Seed a new RNG from the old one? Or we could pull in e.g. a PCG RNG explicitly and benefit from their clone impl.

[ww-oai]

Flagging for viz: I'm taking a look at this now. I'm pretty sure I can eliminate the need for some of the fallibility by switching to PCG where a CSPRNG isn't needed. There's one place (FWICT) where we'll need StdRng::try_from_rng, but IMO panicking there is probably acceptable (given that it's the explicit version of what was happening implicitly with 0.9).

(Note: I'm not super familiar with QUIC; my understanding from some quick research is that using a PCG instance for randomness is OK in the context of BBR since a CSPRNG isn't needed for randomness in flow/congestion control.)

[Ralith]

PCG is overkill, if anything, yeah.

[ww-oai]

Thanks! I'll try and have a PR up by EOD today.