Review `component` public API

[codeboten]

Before considering component 1.0, we need to review the public API to ensure what is exposed makes sense https://pkg.go.dev/go.opentelemetry.io/collector/component

[codeboten]

Some thoughts:

• should BuildInfo be in this package? since its more directly tied to the service running, it might make more sense to move it to that package
• TelemetrySettings should be moved into the telemetry package

[bogdandrutu]

should BuildInfo be in this package? since its more directly tied to the service running, it might make more sense to move it to that package

I think cannot be moved to the "service" since you need to pass this to components, so will create a circular dependency.

TelemetrySettings should be moved into the telemetry package

Same issue about dependency.

[bogdandrutu]

Before considering component 1.0, we need to review the public API to ensure what is exposed makes sense https://pkg.go.dev/go.opentelemetry.io/collector/component

@codeboten we also need to make sure that "consumer" package is 1.0 before :)

[mx-psi]

IMO BuildInfo does not make sense in service: the components should not know anything about the service other than through the component.Host interface; ideally we should be able to completely replace service with a new implementation without changing anything about the components.

For TelemetrySettings, I think it makes sense to move it to telemetry, but my proposal would be to make telemetry into a separate module outside of service. I want to work on this at some point, but haven't gotten around to it lately.

[mx-psi]

I am wondering if we should split component into further packages. For example, we could have componentstatus and componentfactory as separate packages. It currently feels like a mish-mash of important but unrelated things