Add a deterministic constructor for RandomState

[bkragl]

RandomState is the default hasher for std::collections::{HashMap, HashSet}. Today, the only way to construct a RandomState is via RandomState:new(), which generates fresh random keys on every call. That's a good default for security, but it makes testing challenging, because test failures might not be reproducible due to nondeterministic behavior.

Although in principle it is possible to use other deterministic hashers, there are libraries which have hash collections with RandomState hardcoded in their public interface. For example, see aws_sdk_dynamodb (and this discussion).

This change adds a new constructor for RandomState that returns a fixed value, which makes it possible for programs to behave deterministically even if they are locked in to RandomState for hashing.

ACP: rust-lang/libs-team#523

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jhpratt (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[tbu-]

RandomState is the default hasher for std::collections::{HashMap, HashSet}. Today, the only way to construct a RandomState is via RandomState:new(), which generates fresh random keys on every call. That's a good default for security, but it makes testing challenging, because test failures might not be reproducible due to nondeterministic behavior.

Can you give an example where this appeared as a problem?

[Noratrieb]

Thank you for the PR! This PR contains a public library API change, which should follow the proper process of creating an ACP first: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html
Use @rustbot ready when your ACP has been accepeted.
@rustbot author

[bkragl]

Thanks for pointing me to the ACP process. I've opened rust-lang/libs-team#523.

(Side note: It would be awesome to have a master flow chart that guides through the process for any possible Rust contribution scenario. I missed the ACP process because it wasn't mentioned in the "Library Tracking Issue" template.)