Move most capabilities out of the core.Engine in preparation for removal

[na--]

This built on top of #2812 and is the penultimate PR before #1889 🎉 🤞

It splits off as much of the capabilities of the Engine as it's possible to do and keep most of its tests (mostly) intact 😅 Commits should be atomic and it might be easier to review the PR commit by commit. I can even split this into smaller PRs, if needs be, though I think grouping these commits together in one PR and completely removing the Engine in another PR makes the most sense.

[codecov-commenter]

Codecov Report

Merging #2813 (d0eb9d3) into master (daa866a) will increase coverage by 0.06%.
The diff coverage is 94.16%.

@@            Coverage Diff             @@
##           master    #2813      +/-   ##
==========================================
+ Coverage   76.78%   76.84%   +0.06%     
==========================================
  Files         226      225       -1     
  Lines       16848    16807      -41     
==========================================
- Hits        12936    12915      -21     
+ Misses       3084     3066      -18     
+ Partials      828      826       -2     

Flag	Coverage Δ
ubuntu	76.65% <94.16%> (-0.03%)	⬇️
windows	76.52% <93.43%> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
api/v1/setup_teardown_routes.go	58.82% <60.00%> (+0.92%)	⬆️
api/v1/status_routes.go	51.02% <87.50%> (-1.07%)	⬇️
api/v1/routes.go	55.31% <90.00%> (ø)
core/engine.go	85.36% <92.85%> (-8.98%)	⬇️
metrics/engine/engine.go	84.82% <94.87%> (+4.05%)	⬆️
api/server.go	82.60% <100.00%> (+1.65%)	⬆️
api/v1/group_routes.go	57.14% <100.00%> (-3.73%)	⬇️
api/v1/metric_routes.go	77.77% <100.00%> (-1.54%)	⬇️
api/v1/status.go	100.00% <100.00%> (ø)
api/v1/status_jsonapi.go	100.00% <100.00%> (ø)
... and 11 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[olegbespalov]

@na-- For staring the code review could you please resolve conflicts, thanks!

[codebien]

Out of curiosity, do we have an issue with it? I didn't find much searching by Runner.

[na--]

Hmm I don't think we have a dedicated issue for that 🤔 We have a few code TODOs like this one, and some tangentially related issues like #1048 and #2869, but nothing dedicated 🤔

The problem is that we (or at least I) don't have a clear vision for how it should refactored yet... For example, I know that we need to change the name, since Runner is super confusing when it is essentially a "factory" for VUs... 😅 But since I don't have a clear idea how we can refactor it, I also don't know into what to rename it 😞

So yeah, this is why we have the TODO here and in the Runner:

k6/lib/runner.go

Lines 41 to 85 in 1d99b0b

	// A Runner is a factory for VUs. It should precompute as much as possible upon
	// creation (parse ASTs, load files into memory, etc.), so that spawning VUs
	// becomes as fast as possible. The Runner doesn't actually *do* anything in
	// itself, the ExecutionScheduler is responsible for wrapping and scheduling
	// these VUs for execution.
	//
	// TODO: Rename this to something more obvious? This name made sense a very long
	// time ago.
	type Runner interface {
	// Creates an Archive of the runner. There should be a corresponding NewFromArchive() function
	// that will restore the runner from the archive.
	MakeArchive() *Archive
	// Spawns a new VU. It's fine to make this function rather heavy, if it means a performance
	// improvement at runtime. Remember, this is called once per VU and normally only at the start
	// of a test - RunOnce() may be called hundreds of thousands of times, and must be fast.
	NewVU(ctx context.Context, idLocal, idGlobal uint64, out chan<- metrics.SampleContainer) (InitializedVU, error)
	// Runs pre-test setup, if applicable.
	Setup(ctx context.Context, out chan<- metrics.SampleContainer) error
	// Returns json representation of the setup data if setup() is specified and run, nil otherwise
	GetSetupData() []byte
	// Saves the externally supplied setup data as json in the runner
	SetSetupData([]byte)
	// Runs post-test teardown, if applicable.
	Teardown(ctx context.Context, out chan<- metrics.SampleContainer) error
	// Returns the default (root) Group.
	GetDefaultGroup() *Group
	// Get and set options. The initial value will be whatever the script specifies (for JS,
	// `export let options = {}`); cmd/run.go will mix this in with CLI-, config- and env-provided
	// values and write it back to the runner.
	GetOptions() Options
	SetOptions(opts Options) error
	// Returns whether the given name is an exported and executable
	// function in the script.
	IsExecutable(string) bool
	HandleSummary(context.Context, *Summary) (map[string]io.Reader, error)
	}

I also have some very vague ideas on how to refactor setup/teardown/handleSummary handling so they don't require their own dedicated methods, and also how to refactor the archive handling to be somewhat separate, but everything is super vague at the moment and probably full of problems 😞 Someone needs to start doing it, so we can hit the real issues.

[na--]

Decided to create a new issue after all: #2873

Even though we don't have the whole picture, it doesn't hurt to have a place to collect problems that need to be fixed

[imiric]

I don't have major comments, nicely done 👍 And sorry it took so long to review it 😓