[connector,exporter,processor,receiver] Error out on mismatched type

[mx-psi]

Description

Error out on mismatched type for all component kinds. Same as #12305 but for all component kinds.

Link to tracking issue

Requires #12357
Fixes #12221

[codecov]

Codecov Report

Attention: Patch coverage is 77.21519% with 18 lines in your changes missing coverage. Please review.

Project coverage is 92.06%. Comparing base (58f3efb) to head (c582257).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
connector/connector.go	33.33%	12 Missing and 6 partials ⚠️

❌ Your patch status has failed because the patch coverage (77.21%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12381      +/-   ##
==========================================
- Coverage   92.16%   92.06%   -0.11%     
==========================================
  Files         465      469       +4     
  Lines       25201    25323     +122     
==========================================
+ Hits        23226    23313      +87     
- Misses       1576     1602      +26     
- Partials      399      408       +9     

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

[bogdandrutu]

Please make sure we have tests for all the main use-cases.

[mx-psi]

@bogdandrutu The remaining contrib failures are interesting. We have quite a few components that use other components under the hood. A couple of examples (but there a few more):

1. The simple Prometheus receiver uses the Prometheus receiver and has a simplified configuration
2. The JMX receiver uses an OTLP receiver under the hood

How should these components use the API? I think this is also interesting for telemetry: if a component creates other components under the hood, what should its telemetry look like? cc @djaglowski @jade-guiton-dd in case you have thoughts about this

[jade-guiton-dd]

• Regarding telemetry:

  The component-related attributes defined in the RFC only really work within the context of a standard Collector pipeline (because of otelcol.pipeline.id) and configuration (because of the "config name" part of otelcol.component.id), so I think components that are created manually and used as part of an opaque "sub-pipeline" like that should just inherit the attributes of their containing component. This should happen by default with Wrap TelemetrySettings providers to add component-identifying attributes #12384 as long as the parent component passes the TelemetrySettings they received.

• Regarding the API:

  I'm not sure if this kind of "sub-pipeline" should be considered a supported use case of components, so I think the onus should be on component authors to manually adjust the settings passed into the child component to make it work, in this case manually adjusting the component ID.

  If we DO want to support this use case, I think the best way would be some kind of API to create a "derived" receiver/exporter/etc.Settings with the appropriate values for the child component, instead of parents passing their own as-is. We could then adjust the ID accordingly. In the context of component telemetry, we could also add additional extra attributes to identify the source as a child component.

[codeboten]

Is this unblocked now that #12357 is merged?

[mx-psi]

@codeboten I want to fix these first #12381 (comment)

[mx-psi]

Filed open-telemetry/opentelemetry-collector-contrib/pull/38221 for fixing the remaining contrib tests.