Add SysRng behind new feature sys_rng

[dhardy]

This was mentioned elsewhere: rust-random/rand#1675

Adds rand_core as a dependency, which is one small crate.

This attempts to enable testing of rng in all CI tests.

[dhardy]

@newpavlov your opinion on this please?

There is an alternative: the rand_os crate. I slightly prefer fewer crates but either is acceptable.

[newpavlov]

As I wrote previously, personally, I have a slight preference for a separate crate. But I would be fine with this PR as well, if others prefer it.

P.S.: Note that rand_os recently got an "unmaintained" advisory: rustsec/advisory-db#2462

[josephlr]

As I wrote previously, personally, I have a slight preference for a separate crate. But I would be fine with this PR as well, if others prefer it.

I think I would slightly lean towards having this as part of getrandom. A non-default additive feature seems like a good fit. I think the only complexity is figuring out what (if anything) this crate should re-export from rand_core.

[dhardy]

Thanks for moving this forward @josephlr. I think I addressed your concerns (except as commented).

[dhardy]

@newpavlov I addressed your concerns

[newpavlov]

@josephlr
WDYT? It looks like the only unresolved question is whether we need to introduce UnwrappedSysRng or not.

@dhardy
Please add #![cfg_attr(docsrs, feature(doc_cfg))] as per the comment above and add a changelog entry.

[dhardy]

@newpavlov see lib.rs:12.

[dhardy]

A consequence of renaming the feature to sys_rng is:

Would it be better just to name the feature rng?

[dhardy]

I added UnwrappedSysRng (with a slight doc tweak)

[newpavlov]

What about changelog?

It could worth to add test_unwrapped_sys_rng.

Would it be better just to name the feature rng?

Personally, I don't see a problem with the provided rendering.

[dhardy]

Added CHANGELOG entry and test case.

[josephlr]

LGTM (sorry for the delay on review), will respond about UnwrappedSysRng in #754