Inline StepRng

[djc]

This has been deprecated upstream. Inlining a simplified copy of the upstream code seems like the easiest solution to the problem we're solving here (testing the reserved transport parameter ID generation code for edge cases).

[Ralith]

The deprecation PR makes a credible argument that code, such as ours, which isn't implementing a primitive (i.e. next_u64-based) distribution shouldn't be using this at all. IIUC the intent of this test is just to run the generator a bunch and sanity-check its outputs. Should we switch to a single instance of a stable real RNG instead?

[djc]

Should we switch to a single instance of a stable real RNG instead?

The test code here seems carefully constructed to test a bunch of edge cases that might occur. We wouldn't get that level of coverage from switching to a real RNG, right?

[Ralith]

My concern is that the proposition that those edge cases are, in fact, being exercised relies on assumptions about the implementation of random_range that may not be true today, much less forever.

[Ralith]

Let's get this in to unblock the update in the short term regardless.