The `tokio::select!` macro polls branches in a random order. While this
is desirable in production, for testing purposes a more deterministic
approach can be useul.

This change adds an additional parameter to the runtime `Builder` to set
the random number generator seed. This value is then used to reset the
seed on all threads associated with the runtime being built.

This guarantees that calls to the `tokio::select!` macro which are
performed in the same order on the same thread will poll branches in the
same order.

NOTE: This change doesn't correct the handling of the RngSeed on the
thread the runtime is started from, so it's all likely to change. Just
pushing for safety.

Instead of exposing the width of the seed we're currently using, expose
an opaque struct which can generate a seed from a byte slice.

Additionally, each thread is given with a unique seed based on its `id`
(`worker_thread_index`). This should enable more deterministic behavior,
while ensuring that each thread does not begin with the same seed.

In order to properly clean up after ourselves, we set a specific seed
into the thread local RNG when entering into a runtime context. The
previous seed (RNG state) is stored in the `EnterGuard` together with
the previous context (runtime handle). Upon dropping the guard, the
previously stored seed is returned to the thread local RNG.

To achieve this in a deterministic, but fair way, we now store a seed
generator in the runtime handle, and another in the blocking thread
spawner. These seed generators are thread safe (as the one in the handle
may be passed across thread boundries) and will produce a deterministic
series of seeds when the initial seed provided to the seed generator is
the same.

Extended the implementation to also seed the random number generator
used by workers to pick the initial peer to attempt to steal work from.
This change was included in the builder function docs.

…uilder-rng-seed

…uilder-rng-seed

…uilder-rng-seed

…uilder-rng-seed

…uilder-rng-seed

In order to test out the new API before fixing on it, make it unstable
first.

…uilder-rng-seed

It shouldn't have been in the first place.

…uilder-rng-seed

Co-authored-by: Carl Lerche <me@carllerche.com>

Co-authored-by: Carl Lerche <me@carllerche.com>

…kio into hds/runtime-builder-rng-seed

Now that the runtime module is present even without the rt feature.

…uilder-rng-seed

Also fixed a couple of internal comments.