Add file configuration ComponentProvider support for exporters

[jack-berg]

Followup to #6457, adding file configuration support for custom SpanExporter, MetricExporter, LogRecordExporter.

As a part of this, adds ComponentProvider implementations for all the exporters maintained in this module.

[codecov]

Codecov Report

Attention: Patch coverage is 80.67797% with 57 lines in your changes missing coverage. Please review.

Project coverage is 90.50%. Comparing base (3fa57f9) to head (a65a721).

Files	Patch %	Lines
...lemetry/exporter/otlp/internal/OtlpConfigUtil.java	71.42%	12 Missing and 8 partials ⚠️
...elemetry/sdk/autoconfigure/internal/SpiHelper.java	59.09%	8 Missing and 1 partial ⚠️
...lemetry/exporter/internal/ExporterBuilderUtil.java	22.22%	6 Missing and 1 partial ⚠️
...incubator/fileconfig/LogRecordExporterFactory.java	70.58%	4 Missing and 1 partial ⚠️
...sion/incubator/fileconfig/SpanExporterFactory.java	73.68%	4 Missing and 1 partial ⚠️
...on/incubator/fileconfig/MetricExporterFactory.java	75.00%	3 Missing and 1 partial ⚠️
...ternal/OtlpLogRecordExporterComponentProvider.java	93.54%	1 Missing and 1 partial ⚠️
.../internal/OtlpMetricExporterComponentProvider.java	94.87%	1 Missing and 1 partial ⚠️
...lp/internal/OtlpSpanExporterComponentProvider.java	93.54%	1 Missing and 1 partial ⚠️
...nal/ConsoleLogRecordExporterComponentProvider.java	75.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6493      +/-   ##
============================================
- Coverage     90.62%   90.50%   -0.13%     
- Complexity     6261     6281      +20     
============================================
  Files           689      696       +7     
  Lines         18704    18845     +141     
  Branches       1844     1843       -1     
============================================
+ Hits          16951    17055     +104     
- Misses         1198     1223      +25     
- Partials        555      567      +12     

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

[jkwatson]

Is returning nulls from these Factory implementations a pattern that we like? I looked at the interface definition, and it didn't seem to imply that null return value was acceptable.

interface Factory<ModelT, ResultT> {

  /**
   * Interpret the model and create {@link ResultT} with corresponding configuration.
   *
   * @param model the configuration model
   * @param spiHelper the service loader helper
   * @param closeables mutable list of closeables created
   * @return the {@link ResultT}
   */
  ResultT create(@Nullable ModelT model, SpiHelper spiHelper, List<Closeable> closeables);
}

[jack-berg]

I think the contract of the parent Factory interface should probably be adjusted.

Currently, the contract is ResultT create(@Nullable ModelT model, SpiHelper spiHelper, List<Closeable> closeables), so it can accept a null model but is always expected to either return (or throw). This is odd. Always returning when the model is null means that every type has to have some no-op or default representation, which is too strict. Throwing when the model is nullable is a weird pattern too. Why allow the model to be nullable if its just going to throw NPE?

So I think we (i.e. me) need to adjust the factory contract to be consistent: Either both the input model and response are nullabe, OR neither is nullable. And it seems best if neither the input or the response is null. This means that callers have to do some additional work to ensure they're not working with a null model, but should be a good thing in net.

If you're on board, I'll open up an issue and follow up. For the purposes of this PR, there is no appropriate MetricExporter to return when the input model is null, so we need to throw an exception or return null. Returning null is preferable because it is handled by the caller and we can generate a more appropriate error message in MetricReaderFactory than we can in MetricExporterFactory:

opentelemetry-java/sdk-extensions/incubator/src/main/java/io/opentelemetry/sdk/extension/incubator/fileconfig/MetricReaderFactory.java

Lines 49 to 53 in 9a13f68

	io.opentelemetry.sdk.metrics.export.MetricExporter metricExporter =
	MetricExporterFactory.getInstance().create(exporterModel, spiHelper, closeables);
	if (metricExporter == null) {
	throw new ConfigurationException("exporter required for periodic reader");
	}

[jkwatson]

Seems totally reasonable to me to adjust the interface to reflect what appears to be the reality. The other Option (heh) would be to return Optional<ResultT> from the interface, which might signal the correct semantics? Since this isn't a hot-path interface, I think we should at least consider it.

[jack-berg]

Created #6612 to refactor away from using nullable in the factory contract. Not sure why I thought that was necessary, but it was clearly a mistake.

[jkwatson]

Any thoughts on using Optional?

[jack-berg]

The need for optional goes away when we embrace avoiding null. Once you eliminate the ability for Factory to accept a @Nullable model, there aren't actually any cases where its useful to return Optional.empty(). When model is always non-null, Factory should always returns a valid component or throws ConfigurationException.

[jkwatson]

Doh! I completely misread what you did over in the other PR. Thanks! Great refactoring of that!

[jkwatson]

Generally seems good to me. A couple of comments provided.

[jack-berg]

@open-telemetry/java-approvers could use a look when you have a chance. Thanks!