Random::ISAAC: fix initial seed

[asterite]

Fixes #7976

In the old code unsafe_as returned a copy of the static array and so it was initializing something else other than what was returned.

[asterite]

This spec might fail, but it's veeeeery unlikely.

[asterite]

Any other way to test this? Otherwise I can remove the test altogether.

[ysbaddaden]

What about an uninitialized UInt8[32], fill it in one call to random_bytes instead of 8 calls to rand, then cast it to a StaticArray(UInt32, 8)?

That would spare 7 unbuffered reads from urandom (or 7 calls to getrandom, arc4random, ...) yet fix the issue, wouldn't it?

[asterite]

I think so, yes, but to do that we need to use "unsafe_as". I wanted to avoid unsafe code. But I'll try it anyway.

Another idea is to have such code in Secure::Random, somehow, so that it's unsafe but in a single place.

[asterite]

Updated!

I added a general Random#rand(StaticArray(T, N)) that, for now, only works with integer types. Its implementation uses unsafe_as but it's not really unsafe (or it shouldn't be).

Then I used that method in the initialization of Random::ISSAC seed.

In the future I'd also like to be able to do rand(Int32), rand(UInt64) and so on.

[asterite]

I'll do it differently.

[asterite]

Added more things and implemented it in a way that's easier to read in docs (now there's one overload per static array type).

Also added the ability to do rand(Int32), rand(Int8) and so on, to get a value in that type's range. For that I use random_bytes to fill all bytes and then cast it to that type (same thing as with static arrays). I don't know if that's sound but we could eventually change the implementation if needed.

[oprypin]

It's strange to have a separate implementation for this when rand(type::MIN..type::MAX) works fine.

Also kind of funny that random_bytes unrolls integers into bytes (and inverts for endinanness) and then this rolls them back into an integer (without inverting for endianness - though double-inverting would also be weird).

So yes, this implementation is endianness-dependent, unlike everything else.

And then, just by coincidence,
Random.new(x).rand(Int32::MIN..Int32::MAX) == Random.new(x).rand(Int32)
but
Random.new(x).rand(Int64::MIN..Int64::MAX) != Random.new(x).rand(Int64)