CHANGE: Re-enable `ReseedingRng`

Summary

How does this affect the API / end-user? (Include API-breaking changes, value-breaking changes and API additions.)

rand's user can access the ReseedingRng struct that was previously avaible until rand v0.10. This struct has been removed in v0.10. A related issue: https://github.com/rust-random/rand/issues/1721.

Details

What changes does this require internally?

It might be as simple as reverting this PR: https://github.com/rust-random/rand/pull/1722.

git revert bfa14ab4d0f2a5c161478aafe4a1edee02547f03

Essentially, we would like this struct to be made available, instead of be deprecated completely.

Motivation

What is the motivation for this change?

Since every change has a cost (even if just API churn or extra code size), every change must have sufficient motivation. This is arguably the most important part of the RFC.

We use rand for generating random bytes in s2n-quic: a rust implementation of the QUIC protocol. We use rand for both public and private generator. We will add more details about how we use ReseedingRng in our own issue: https://github.com/aws/s2n-quic/issues/2986.

Alternatives

Which alternatives might be considered, and why or why not?

One alternative is to implement a ReseedingRng wrapper in s2n-quic for our own usage. I think having it from rand is more preferable.

Start by reviewing PR #1722 and commit bfa14ab4d0f2a5c161478aafe4a1edee02547f03, then compare the current rand v0.10 API with the ReseedingRng documentation linked in the issue. Done means ReseedingRng is publicly available again rather than only deprecated, with the affected API behavior verified.