Add a randomized test for the variable-looping-vus requirements

[na--]

I gave up on completely understanding all of the corner cases of #1392, or on simplifying it... for now... 😅 But here's an extra test that hopefully validates that however we segment a variable-looping-vus executor, it will always execute what it would have executed if it was running on a single machine.

Whether that execution is completely correct is another topic 😄 My manual tests didn't find any issues there, but I would still want some easier to follow implementation eventually, maybe when we adapt it to data partitioning.

[mstoykov]

I have some readability comments, but otherwise looks Okay ;)

I was thinking of doing it by adding up all the segments steps .. but this is probably better and seems simpler then what I thought adding up will be :D

[na--]

I was thinking of doing it by adding up all the segments steps

This would definitely be more complicated. I was going to refactor GetFullExecutionRequirements(), to use it here as well, but it ended up nasty, and wasn't worth it just for this test, so I sort of implemented the reverse of it, which was much simpler.

[na--]

@mstoykov I think we should first merge this in your branch, despite the unrelated failing CDNJS test, and then you can rebase on new-schedulers, where the test has been silenced?

[imiric]

This test is very noisy when run with -v, which I usually enable to see the full output, but now this test prints ~80K lines, forcing me to use tee, etc. :-/

Can we use a debug logger here?

[mstoykov]

I am for commenting all the Logf lines and leaving only the random seed one as that is needed to get it reproduced - if you get an error on this, trust me you would want to be able to reproduce it ... the size of the output is way too big to just read it in circleci for example