Add example for using global variables

[heitortsergent]

What?

Add a page explaining how to use global variables in k6.

Checklist

• I have used a meaningful title for the PR.
• I have described the changes I've made in the "What?" section above.
• I have performed a self-review of my changes.
• I have run the npm start command locally and verified that the changes look good.

• I have made my changes in the docs/sources/k6/next folder of the documentation.
• I have reflected my changes in the docs/sources/k6/v{most_recent_release} folder of the documentation.
• I have reflected my changes in the relevant folders of the two previous k6 versions of the documentation (if still applicable to previous versions).

[heitortsergent]

@tom-miseur @oleiade this is my draft for adding the example of how to use global variables. If you could please take a look and let me know what you think, I could definitely use some help with the explanations of each option. 🙇

[oleiade]

There is an important caveat we should mention somehow here, which is that modification of variables defined in the init context will be local to the VUs they're made in.

An expectation I often see arise from users is to treat global objects defined in the init context, as if they were just that: a standard JS object that you can modify during your test. However, because k6 is essentially a worker pool, and our workers (VUs) work in isolation from each other, that assumption does not convert to reality for most uses.

So in practice, if the example was setting options to define say 8 VUs, and a multiple of 8 iterations, then each execution of the default function would see a prop value that's local to the VU executing the iterations.

In practice, my observation is that most users will expect that with 2 VUs and 4 iterations, incrementing the var prop would lead to its value being 8 at the end of the test, whereas in reality it will be 4 for the first VU, and 4 for the second VU.

I would keep the example as-is, but somehow remind the VU model, and insist that for read-only use-cases, where users either use a static value in their global object, or set it only once at the begining of the test (in setup for instance); no problem. But as soon as they write to it, they need to be aware that the code is gonna be executed concurrently, and that each VU will have its own VARS instance.

I realize this might be a somewhat hairy explanation, but happy to pair on this 🙇🏻