runtime: added standard library compatibility to RandomGenerator

[SaveTheRbtz]

Description:
This adds stdlib's glue code to the Runtime::RandomGenerator implementing UniformRandomBitGenerator requirements. This allows to use RandomGenerator with functions like std::sample, std::shuffle, etc.
It's up to the maintainers' taste whether this code belongs here or in a separate "Adapter" class.

Risk Level: Low
Testing: Added unit test using Runtime::RandomGeneratorImpl with std::shuffle.

[junr03]

@dnoe do you mind taking a look at this?

[dnoe]

Do we ever foresee this changing?

[SaveTheRbtz]

Nope, but it is a part of UniformRandomBitGenerator[1] interface. If it looks ugly/weird inside this class, I can move it to a separate "adaptor" class.

[1] https://en.cppreference.com/w/cpp/named_req/UniformRandomBitGenerator

[derekargueta]

hmmm clang-tidy borked but "passed" the PR cc @lizan

...
Running clang-tidy-diff against master branch...
From https://github.com/envoyproxy/envoy
 * branch            master     -> FETCH_HEAD
fatal: ambiguous argument 'master..HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
No relevant changes found.

(it should be flagging this line because codebase convention is for type aliases to be CamelCase, but can be overridden with // NOLINT(readability-naming-identifier) for cases like this when conforming to a library such as here)

[derekargueta]

opened #9140 to fix clang-tidy

[SaveTheRbtz]

Added lint comment.

[dnoe]

Does this also implicitly exercise min() and max()?

[SaveTheRbtz]

Yeah, std::uniform_int_distribution[1] used underneath std::shuffle uses min() and max()

[1] https://en.cppreference.com/w/cpp/numeric/random/uniform_int_distribution.

[dnoe]

This has obvious flakey test appearance, although the probability of a flake would presumably be very low (https://en.wikipedia.org/wiki/Bogosort comes to mind 😃 ). It's of course also possible that a perfectly correct random number generator results in the same shuffle occurring two times in a row, but this does seem extremely unlikely.

In practice, if you can execute this test a few times with some very high ``--runs_per_test` value like 10000+ and no problems maybe it's OK. Have you tried that?

[SaveTheRbtz]

Yep, theoretically there is ~10000/100! chance of that test failing which is practically impossible. Nevertheless I did run it overnight to confirm that this won't happen:

  Stats over 10000 runs: max = 20.2s, min = 5.7s, avg = 8.7s, dev = 2.8s

[dnoe]

Thanks. FYI, next time, don't force push. It messes things up in the GH review UI.

@lizan can you take a senior maintainer pass and merge if it looks good to you?

[SaveTheRbtz]

test failure is due to redirect_integration_test (#9145)