[otelcol] update to use confmap unmarshal validation instead of invoking top-level Validate function manually.

[TylerHelmuth]

Description

Mockup of what it could look like to use confmap validation in otelcol.

Link to tracking issue

Related to #11524

Testing

Would need actual unit test updates

[evan-bradley]

Just giving this a quick pass, I like that we hoisted the calls to validate the config out of the (otelcol.Config).Validate function. Overall this seems like an improvement, even if only because it removes responsibility from otelcol.

Given the PoC, what do you think about this change?

[TylerHelmuth]

Given the PoC, what do you think about this change?

I like utilizing Validate on configSettings more than trying to unmarshal directly into otelcol.Config, but while I was implementing this I realized that it would be a lot safer/wholistic if validation was enabled by default and there was an option to disable it.

I ran into an issue in the unmarshalHookFunction where I could not specify all custom unmarshal implementations to use confmap.WithInvokeValidate. The result was that the configSettings fields like Recievers that have a custom unmarshal implementation needed to be manually updated to use confmap.WithInvokeValidate.

This update allows the top-level unmarshalling to validate correctly, which means that component unmarshal implementations don't need to use confmap.WithInvokeValidate (otlpreceiver validation still worked for example), but it feels risky. It feels like there are other opportunities for holes.

The other thing I don't care for is we can no longer differentiate between errors retrieving the configuration and validating the retrieved config. When this was separate steps before we new which step was erroring - now in order to differentiate we'd need special error types.