Redesign dependency structure

[DifferentialOrange]

Part of tarantool/tarantool#7725

It first started when I was needed to define the order of module files to load. And there were several unexpected surprises.

To begin with, having requires inside functions already seems like a smell of a bad dependency structure.

What's external and what's internal for the package?

External:

• metrics,
• metrics.plugins.*,
• cartridge.roles.metrics,
• metrics.psutils.cpu.

Users require metrics to work with metrics, metrics plugins to export metrics, cartridge role to work with metrics from cartridge. The latter one is a weird one -- it's something like an old default metrics, so we won't discuss it.

It makes sense for plugins and cartridge role to depend on main metrics package since it's a wrapper. What makes less sense is that more than half of the internal package scripts (metrics.tarantool.* and others) depend on the main metrics package. They are not expected to be used directly be the user, only through the main package (yeah, it is as confusing as it sounds). So the questionable places are

and

and all in-function requires (the only one not covered by the two schemes above is a weird require of metrics.collector.* in HTTP middleware).

Such structure is also a block to some planned tarantool/tarantool#7725 features (specifically, metrics.cfg reload support) and it makes introducing new features (like whole metrics.cfg) more confusing.

[DifferentialOrange]

(I've made a separate issue to store the pictures somewhere since it's hard to embed in a commit message.)