Fix ThreadLocalRandom

[isaacl]

Current impl was not creating thread local randoms!

[isaacl]

Note: there's other ways to fix this -- you could have a singleton RandomApi wrapper that gets it's underlying ThreadLocalRandom implicitly... But it definitely needs to be fixed!

[isaacl]

@ornicar ^

[niklasf]

Good find! This could potentially be pretty bad. Looks like ThreadLocalRandom.current() is already using a thread-local internally, so we could just call that instead of wrapping it in another one?

[isaacl]

Sorry this isn't actually good enough, because there are multithreaded classes which import a ThreadLocalRandom top level object and then might use it in multiple threads. PR follow up coming

[isaacl]

See #54

[isaacl]

@niklasf my read of the code is that the old impl causes a lot of uninitialized random sources which will all have the same sequence. ThreadLocalRandom.current always returns the same singleton object (which internally uses storage on fields of the Thread class to manage state). But without the call to current on each thread, the random source spits out values without initialization. And once it spits out a value, it no longer thinks it needs to be initialized.