[confmap] Pass ConverterSettings and ProviderSettings to converters and providers

[mx-psi]

Description:

For both #5615 and #9162 we need to be able to log during the confmap resolution.

My proposed solution is to pass a *zap.Logger to converters and providers during initialization. These components can then use this to log any warnings they need. This PR does the first step: being able to pass anything to converters and providers during initialization.

The obvious alternative to this is to change the interface of confmap.Provider and confmap.Converter to pass any warnings in an explicit struct. I think the *zap.Logger alternative is more natural for developers of providers and converters: you just use a logger like everywhere else in the Collector.

One problem for the Collector usage of confmap is: How does one pass a *zap.Logger before knowing how a *zap.Logger should be configured? I think we can work around this by:

1. Passing a special 'deferred' Logger that just stores the warnings without actually logging them (we can use something like zaptest/observer for this)
2. Resolving configuration
3. Building a *zap.Logger with said configuration
4. Logging the entries stored in (1) with the logger from (3) (using zaptest/observer we can do that by taking the zapcore.Core out of the logger and manually writing)

We don't actually need ProviderSettings today, just ConverterSettings, but I think it can still be useful.

Link to tracking Issue: Relates to #5615 and #9162

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f37e376) 90.24% compared to head (5f87038) 90.27%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9443      +/-   ##
==========================================
+ Coverage   90.24%   90.27%   +0.02%     
==========================================
  Files         344      344              
  Lines       17932    17955      +23     
==========================================
+ Hits        16182    16208      +26     
+ Misses       1421     1419       -2     
+ Partials      329      328       -1     

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

[evan-bradley]

Looks good to me. I like this approach versus the alternative of adding parameters/return values to the interface method signatures. If we still want to use a type we make ourselves instead of zap.Logger, we could pass that in as a field in the Settings struct.

There may be some considerations we will need to take into account with the logger (how do we work around constructing a zap.Logger from the config if the config fails to resolve?) but those can be addressed later.

[bogdandrutu]

We don't actually need ProviderSettings today, just ConverterSettings, but I think it can still be useful.

At one point I was very close to remove EnvConvertor (for some personal reasons I dropped that effort to not have to deal with more issues). Is that an alternative to both issues?

• We have expanding available (and recursive) in the confmap resolver which supports almost all cases of the EnvConvertor.