[stacked 5/5] metrics: add topology-aware policy metrics collection.

[klihub]

Notes: This PR is stacked on top of #405.

Implement metrics collection for the topology-aware policy. Currently we collect for each pool/zone
- name, cpuset and memset
- shared pool capacity, allocation, available amount
- memory capacity, allocation, available amount
- number of containers
- number of containers in the shared pool

[pfl]

LGTM

[fmuyassarov]

This looks pretty good. There might be some minor nits but I think it is easier if we move with the it now and improve further as follow ups if required. Thank you @klihub for the great work.

[askervin]

LGTM. Huge work.

[askervin]

Such a nice framework. I think we can extend this easily later on to users who wish to get per-container metrics, like how many exclusive CPUs my container has, etc. And metrics overhead can by controlled by enabling/disabling this in configuration.

Hats off to @klihub.

[klihub]

Such a nice framework. I think we can extend this easily later on to users who wish to get per-container metrics, like how many exclusive CPUs my container has, etc. And metrics overhead can by controlled by enabling/disabling this in configuration.

Hats off to @klihub.

Now that you mentioned, I think there's one more thing that we might need to add for computationally expensive metrics. The programmatic ability to check if a collector is enabled (probably simply by name with something like metrics.Registry.IsEnabled(name string) bool), so that expensive collectors which neither use throwaway/const metrics nor recalculate themselves during collection (but other normal operations like resource allocation and release) can know when to disable the expensive updates.