Add 'pipeline' attribute to processor metrics

[djaglowski]

Resolves #10908

This ends up being a pretty straightforward change in actual code, but a tedious change in tests. It's also obviously a breaking change for anyone depending on these metrics.

[codecov]

Codecov Report

Attention: Patch coverage is 31.03448% with 20 lines in your changes missing coverage. Please review.

Project coverage is 91.80%. Comparing base (df3c9e3) to head (b8ddb2a).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
component/componenttest/otelchecker.go	0.00%	12 Missing ⚠️
component/componenttest/obsreporttest.go	0.00%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #11171      +/-   ##
==========================================
- Coverage   91.87%   91.80%   -0.08%     
==========================================
  Files         421      422       +1     
  Lines       19989    20005      +16     
==========================================
  Hits        18365    18365              
- Misses       1249     1265      +16     
  Partials      375      375              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djaglowski]

One notable detail is that the otel.signal attribute added in #11144 is arguably redundant, since pipeline ID's contain the data type. However, we likely will want otel.signal for receiver and exporter metrics as well, so perhaps it makes sense to leave it. (Connector metrics would need to differentiate between incoming and outgoing data type though.)

[mx-psi]

The approach looks reasonable to me. There are some breaking changes on the test modules, I feel like those are okay (and that maybe we should split that part of the modules off to make our lives easier, but that's for another PR)

[djaglowski]

The approach looks reasonable to me. There are some breaking changes on the test modules, I feel like those are okay (and that maybe we should split that part of the modules off to make our lives easier, but that's for another PR)

I added a changelog to note to breaking change in processortest.NewNopSettings

[djaglowski]

I opened #11179 to capture thoughts on the broader question of which attributes to apply to each kind of component. This PR aligns with what I believe is the best overall schema, but please take a look.

[mx-psi]

Any thoughts on whether we should require this argument for other test packages, just for consistency? The situation I am worried about is that we eventually want to pass the pipeline ID for some reason (not necessarily self telemetry) for all components and we end up having to change it everywhere

[djaglowski]

It seems likely we'll want to include the data type for other component kinds. I suppose we could pass the pipeline ID here for processors, but not sure there's any case to do it for other kinds. This is probably something worth trying to iron out as part of #11179.