Propagate the real context when initializing VUs

[na--]

Currently, VU initialization doesn't receive a context. The last time we propagate the context is here:

k6/core/local/local.go

Lines 172 to 173 in 564197a

	func (e *ExecutionScheduler) initVUsConcurrently(
	ctx context.Context, samplesOut chan<- metrics.SampleContainer, count uint64,

But then we don't pass it to the layers below:

k6/core/local/local.go

Line 182 in 564197a

newVU, err := e.initVU(samplesOut, logger)

k6/core/local/local.go

Line 143 in 564197a

vu, err := e.state.Test.Runner.NewVU(vuIDLocal, vuIDGlobal, samplesOut)

k6/js/runner.go

Lines 115 to 126 in 564197a

	func (r *Runner) NewVU(idLocal, idGlobal uint64, samplesOut chan<- metrics.SampleContainer) (lib.InitializedVU, error) {
	vu, err := r.newVU(idLocal, idGlobal, samplesOut)
	if err != nil {
	return nil, err
	}
	return lib.InitializedVU(vu), nil
	}
	//nolint:funlen
	func (r *Runner) newVU(idLocal, idGlobal uint64, samplesOut chan<- metrics.SampleContainer) (*VU, error) {
	// Instantiate a new bundle, make a VU out of it.
	bi, err := r.Bundle.Instantiate(r.preInitState.Logger, idLocal)

k6/js/bundle.go

Lines 242 to 247 in 564197a

	func (b *Bundle) Instantiate(logger logrus.FieldLogger, vuID uint64) (*BundleInstance, error) {
	// Instantiate the bundle into a new VM using a bound init context. This uses a context with a
	// runtime, but no state, to allow module-provided types to function within the init context.
	vuImpl := &moduleVUImpl{runtime: goja.New()}
	init := newBoundInitContext(b.BaseInitContext, vuImpl)
	if err := b.instantiate(logger, vuImpl.runtime, init, vuID); err != nil {

And, at the end, we end up using context.Background() 😞

k6/js/bundle.go

Line 329 in 564197a

init.moduleVUImpl.ctx = context.Background()

This is not ideal because we don't have any way of aborting the VU initialization if the user hits Ctrl+C or if one of the VUs fails during the concurrent VU initialization and we need to abort the initialization of the rest of the VUs and wait for that to finish quickly (see here and here).

Currently, we just rely on the fact that we'll use os.Exit() to stop k6, however that assumption breaks in a few cases:

• in integration tests, where these dangling VU initializations can emit logs and cause data races, after the test was supposed to be finished (Integration test improvements and a few bugfixes #2789)
• in test suites (Test suites / execute multiple scripts with k6 #1342), where the fact that one test fails may not necessarily mean that the k6 process should exit
• when the --linger option is used, we might want to have the k6 process linger even if there was an init error, same as we'd do if the test was aborted by threshold or execution.test.abort()

In general, the current behavior breaks the very reasonable expectation that once the k6 run command has finished and returned, all of its child goroutines have also finished and returned before it...