Refactor the current way metrics are defined

[na--]

We currently define all possible emitted metrics as shared global variables. As this ugly data race fix shows, that's probably not a very good idea, since the stats.Metric struct seems to contain some mutable fields.

Before embarking on a huge refactoring spree, we should check if the go-metrics library (suggested in this issue) or another one offers us a nicer solution.

[na--]

Most of this issue has been resolved by the metrics Registry introduced by #2071 and the follow-up related PRs like #2433, #2442 and a bunch of refactoring PRs...

However, the mix of metric metadata and mutable state still remains a problem in the Metric struct, this is what the TODO here is about:

k6/metrics/metric.go

Lines 12 to 26 in 27f2ead

	// A Metric defines the shape of a set of data.
	type Metric struct {
	Name string `json:"name"`
	Type MetricType `json:"type"`
	Contains ValueType `json:"contains"`
	// TODO: decouple the metrics from the sinks and thresholds... have them
	// linked, but not in the same struct?
	Tainted null.Bool `json:"tainted"`
	Thresholds Thresholds `json:"thresholds"`
	Submetrics []*Submetric `json:"submetrics"`
	Sub *Submetric `json:"-"`
	Sink Sink `json:"-"`
	Observed bool `json:"-"`
	}

This will hopefully soon be taken care of as well. After we completely remove the core.Engine (PoC for that in #2438, 8850e35 specifically, that will soon be polished and moved into a separate PR), we'll be able to split apart that struct and move the state to only exist in the simpler metrics.MetricsEngine. We can probably also simplify the locking quite a lot then... 🤔

[codebien]

When we will pick this issue, we should check if it makes sense to address #2320 in the same cycle.

[olegbespalov]

For the record. After an internal discussion, we decided to clean a milestone since the issue was jumping between milestones without completion.

Once we determine which milestone it lands, we set the right one.

[mstoykov]

Closed in favor of #3907