Related and derived metrics/samples packing

[llucax]

Coming from #485.

I think there are a few different things at play here that are a bit mixed and made everything more confusing for me:

1. Packing related metrics together. Like 3 phases, different types or power (reactive/active/apparent)
2. Processing one metric and producing several values (like lowest, highest and average) from it (here with the temperature we are doing that)
3. Related to the other 2, how are methods in battery_pool or logical_meter called to get these multiple/related metrics

I think we should stick to the principle of keeping the data pipeline as simple as possible, so at the sample-level, I think we should only have single-valued samples (not sure how fundamentally needed the Sample3Phase is). So in this sense, no, I would rather not add more composed Sample classes.

I also think the pipeline (including the battery_pool or logical_meter) shouldn't produce derived multi-metrics from one individual, like (lowest, highest, average), I think that should be done in a higher level, as it is also something that can be applied generically to any metric/sample, not just temperature. It is different if we need to derive a metric from some other because it is not provided directly, like we get voltage and current as metris and we need to get power, then I think the battery_pool should do that.

I'm also not sure how this plays with pools, as for some metrics we want to be able to provide the individual values for each component in the pool, right?

So about 3, if we get 3 different metrics, apparent power, reactive power and active power, then from the API POV, for me the nicest would be to have:

battery_pool.power.active
battery_pool.power.reactive
battery_pool.power.apparent

Again, all I'm saying here is what I think is the best in abstract, maybe reality says something else.

[llucax]

FYI @frequenz-floss/python-sdk-team