Introduce additional consumer packages split by telemetry type

[dmitryax]

This change adds another set of packages representing "consumer" split by telemetry signal type. The same approach is taken as for the pdata split. Common parts are moved to internal package and then they are used from both existing combined and split consumer packages.

This is just one step towards splitting the pdata usage to illustrate one option of new pdata structure as suggested in this PR: #4918

[codecov]

Codecov Report

Merging #5086 (ff21a71) into main (a13c2dd) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #5086   +/-   ##
=======================================
  Coverage   90.11%   90.11%           
=======================================
  Files         183      183           
  Lines       11022    11022           
=======================================
  Hits         9932     9932           
  Misses        867      867           
  Partials      223      223           

Impacted Files	Coverage Δ
model/internal/pdata/generated_logs.go	96.65% <ø> (ø)
model/internal/pdata/generated_traces.go	96.89% <ø> (ø)
consumer/internal/consumer.go	100.00% <100.00%> (ø)
consumer/consumer.go

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a13c2dd...ff21a71. Read the comment docs.

[bogdandrutu]

I think during the discussion about the split of pdata we agreed that we are not going to split all the packages, only pdata. I want to make sure we do not go on a different direction.

[mx-psi]

I think during the discussion about the split of pdata we agreed that we are not going to split all the packages, only pdata. I want to make sure we do not go on a different direction.

My interpretation of what happened is "we agreed for now on pdata split and nothing else", not "we agreed not to split other packages". I agree if we were to split other stuff by telemetry type, it would need further discussion

[dmitryax]

"we agreed for now on pdata split and nothing else", not "we agreed not to split other packages"

This was my understanding as well. And this PR is just to illustrate how further split can be done to support the further discussion. We need to do "something" with other packages using pdata in order to provide the backward compatible transition to the new pdata packages. This one is a simple example of what can be done for that, others can be more problematic to split, but we have to somehow rename/move them anyway.

[dmitryax]

This one is a simple example of what can be done for that, others can be more problematic to split, but we have to somehow rename/move them anyway

I was wrong here. We don't need to rename or split existing clients of the pdata packages to migrate it. There is a very nice side affect of the alias approach that we took:

Since pdata.<API> and metrics.<API> (or pmetric.<API>) are aliases to the same entities, they can be easily interchanged in all the places where they are being used without breaking it. E.g. if we change interface ConsumeMetrics(ctx context.Context, md pdata.Metrics) error to ConsumeMetrics(ctx context.Context, md metrics.Metrics) error, all existing implementations using pdata.Metrics will keep working.

So we can split pdata packages and deprecate old ones right away. Just need to agree on which pdata structure we are going to use:

• Split pdata package by telemetry signal type #4918
• Split pdata package by telemetry signal type #5087

cc @bogdandrutu @Aneurysm9 @mx-psi