Make the __VU execution control var available in the init phase

[na--]

It could probably be useful for different things, chiefly something like this:

let vuRotated = __VU % 3;
let data = JSON.parse(`./${vuRotated}.json`)

export default function () {
    console.log(`VU #${__VU} sees the following data: ` + JSON.stringify(data));
};

If we have split different static credentials in files named as 0.json, 1.json, and 2.json, each VU will take up only a third of the memory it would have consumed if all of the data was in a single file.

The evaluation needed tag is because it's unclear if there are obstacles for implementing this, or if it can have some negative consequences.

[mstoykov]

Problems:

• what is the value when setup/teardown is being ran ?
• when you run k6 archive how do you know which files should be putted inside the archive?

Both are fixable - the first one could be something like -1 (0 is actual valid value so I would prefer not to use it) , and the second can be fixed with some argument to archive that says "import this files as well" and leave it to the user to do the right thing.

[na--]

The second one is an issue even now, you can use Math.random() to open different files in the init context

[na--]

Just wanted to add a note that implementing this after #1007 would be much better. That's because currently, when VUs are ramped down and then back up again, their __VU number gets reassigned. So even if we add a __VU number in the init context, that number may become different sometime down the line. As an example:

import { sleep } from "k6";

export let options = {
    stages: [
        { target: 10, duration: "5s" },
        { target: 0, duration: "5s" },
        { target: 10, duration: "5s" },
    ],
}
export default function () {
    console.log(__VU)
    sleep(3);
}

The maximum number that will be printed with k6 v0.25.1 is somewhere around 19-20, even though we only ever have 10 VUs at max. With the code from #1007, it's going to always be 10. This is because __VU is currently re-assigned with incremental values when the VU is put back into service during the second ramp-up, whereas in the new code the VU ID is assigned once and never changed.

[na--]

This should be easy enough to fix after #1368 is merged (and probably #1007 itself is merged in master): https://github.com/loadimpact/k6/pull/1368/#discussion_r413783836