Move the stats package content to metrics package

[oleiade]

What this PR is about

Until now, we had two separate stats and metrics packages. Although
their content was related, some components were living in one, some in
the other. It leads to difficulties when having to work with both, and
made cyclic dependencies easy to run into.

To simplify our workflow, and facilitate further developments, this
commit moves the content of the stats package in the top-level
metrics package. As of this commit, the stats package is removed,
and all dependencies using it have been updated to use the metrics
package instead.

Why?

This allows to easily avoid the cyclic dependency issues I've been running into whenever I attempt to touch/refactor the original thresholds code. This also builds upon the refactors made by @na-- in #cleanup-7, and leads them to the finish line 🏁. Moreover, the code between metric and stats as it was laid out before made it sometimes hard to reason about one or the other. I do believe having all these types/concepts in a single place are advantageous.

How to review

🚨 I know, this PR is HUGE 🚨 But, the good news is, you don't even need to look at the changes 🦖. It consists only in moving code around, updating imports, and replacing stats. calls into metrics..

However, I do think it'd be valuable if you could check out the branch, and look at the new structure of the top-level metrics package. I took the liberty to move some types in dedicated files for clarity, but that's really most of the actual changes involved in this.

Dependencies

• This PR is built upon cleanup-7.
• It is meant to support further work on Parse and validate threshold during init #2356

[codebien]

@oleiade Out of curiosity, why stats => to metrics and not the opposite?

[oleiade]

@codebien that's a good question. While discussing this, it emerged that the idea to move things this way was already hanging around. @na-- had already started, so this PR just follows the movement. Besides, I do think that most of the types that have been moved are really related to Metrics, and that it's a better name, but that's really just me 🦖

[na--]

Yeah, in #2426 I needed to add a MetricsEngine somewhere and I wanted for that to not be /lib... 😅 We already had /lib/metrics for the Registry, so:

1. move the /lib/metrics to /metrics directly, to start reducing the things in /lib
2. it felt natural to put it the MetricsEngine under /metrics/engine... (I'd have put it under /metrics directly, but that would cause an import loop 😞 though there is a chance for that to disappear with a bit more refactoring 🤞 )
3. move /stats to /metrics and refactor some of the things there (e.g. completely remove stats.New() and only allow metric creation through a Registry, which btw is one change request I have for this PR after I skimmed it)

At the end of that, we'll be left with a nice self-contained /metrics package that's reasonably clean and technical debt free 🎉 😅 It could have been stats, but the metrics name seems more well suited, esp. for metrics.Registry

[oleiade]

@na-- #2442 addresses the removal of stats.New, and targets master. Once merged we should rebase #cleanup-7 on master (and update #2433 accordingly).

[oleiade]

This PR has been rebased on #2442, which is in turn based on #2426. As far as I can tell, test failures are transitives, and will be automagically fixed as soon as #2426 addresses them.

[na--]

🎉

[codebien]

LGTM 🙇‍♂️