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 https://github.com/grafana/k6/pull/2071 and the follow-up related PRs like https://github.com/grafana/k6/pull/2433, https://github.com/grafana/k6/pull/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: https://github.com/grafana/k6/blob/27f2ead359dac24b4131dac4b57c95c058f06e48/metrics/metric.go#L12-L26

This will hopefully soon be taken care of as well. After we completely remove the core.Engine (PoC for that in https://github.com/grafana/k6/pull/2438, https://github.com/grafana/k6/pull/2438/commits/8850e35c674ff9c2428c35d0db0b202c165e622c 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... :thinking:

[codebien]

When we will pick this issue, we should check if it makes sense to address https://github.com/grafana/k6/issues/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.