Possible improvements for `Random`

[rvanasa]

• We could provide an asynchronous alternative to Random.Finite which automatically replenishes entropy by calling Random.blob(), since this would drastically reduce the complexity of random number generation for common use cases. That being said, it seems reasonable to also keep the current functionality due to the extra overhead from async calls.

[crusso]

I think @ggreif deliberately didn't do that so people don't re-use stale entropy in subsequent rounds, which can be unsafe for some applications that rely on unpredictable randomness. Not sure that applies here, but might.

[ggreif]

If we provide something like that (or a seeded RNG) then I'd prefer to put such functionality into a LowSecurity (or such) submodule.

[rvanasa]

Makes sense. It also seems reasonable to defer this functionality to a third-party library, similar to Rust's rand crate.

[crusso]

Though it would be nice if Random.Finite took a byte iterator, not a finite, blob, so you could give it an infinite supply of bits generated on demand using a PRNG, say.

[ggreif]

Though it would be nice if Random.Finite took a byte iterator, not a finite, blob, so you could give it an infinite supply of bits generated on demand using a PRNG, say.

Then it should be named Random.Stream.