[CONFIGURATION] SDK default component builder libraries and example

[dbarker]

Contributes to #4352

Create configuration builder libraries per signal and update SdkBuilder to use them.

This brings a breaking change to how users create a default registry populated with SDK component builders.

// before this PR
auto registry = std::make_shared<sdk::configuration::Registry>();

// with this PR
auto registry = sdk::configuration::RegistryFactory::Create();

Changes

• creates the per-signal builder libraries
  • opentelemetry-cpp::configuration_logs_builders (9846e83)
  • opentelemetry-cpp::configuration_metrics_builders (f3328f3)
  • opentelemetry-cpp::configuration_trace_builders (7977068)
• creates the registry factory to create a fully populated registry with the default builders
  • openetelemetry-cpp::configuration_registry_factory (d077f5f)
• updates the SdkBuilder to get the new builders from the registry (3c1ba5a)
• enables the batch processor tests in the programmatic configuration test suite (a3442f3)
• updates the sdk and configuration component install tests (d4c7101)
• adds new yaml example (sdk-default.yaml) and test for builds without exporters (69b55ec, 3d02037)
• Adds a CompositeSampler to the model and breaks out composable samplers from the SamplerConfigurationVisttor

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

❌ Patch coverage is 72.64151% with 116 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.99%. Comparing base (7532fca) to head (3b05f9d).

Files with missing lines	Patch %	Lines
sdk/src/configuration/logs_builders.cc	44.71%	47 Missing ⚠️
sdk/src/configuration/sdk_builder.cc	73.30%	47 Missing ⚠️
sdk/src/configuration/trace_builders.cc	86.09%	16 Missing ⚠️
sdk/src/configuration/metrics_builders.cc	76.20%	5 Missing ⚠️
sdk/src/configuration/registry_factory.cc	85.72%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4367      +/-   ##
==========================================
+ Coverage   81.91%   81.99%   +0.09%     
==========================================
  Files         494      501       +7     
  Lines       19658    19835     +177     
==========================================
+ Hits        16101    16262     +161     
- Misses       3557     3573      +16     

Files with missing lines	Coverage Δ
...tion/composable_always_off_sampler_configuration.h	100.00% <ø> (ø)
...ation/composable_always_on_sampler_configuration.h	100.00% <ø> (ø)
...omposable_parent_threshold_sampler_configuration.h	100.00% <ø> (ø)
...ion/composable_probability_sampler_configuration.h	100.00% <ø> (ø)
...figuration/composable_rule_based_sampler_builder.h	100.00% <ø> (ø)
...tion/composable_rule_based_sampler_configuration.h	100.00% <ø> (ø)
...k/configuration/composable_sampler_configuration.h	100.00% <100.00%> (ø)
...uration/composable_sampler_configuration_visitor.h	100.00% <100.00%> (ø)
...etry/sdk/configuration/composite_sampler_builder.h	100.00% <100.00%> (ø)
...dk/configuration/composite_sampler_configuration.h	100.00% <100.00%> (ø)
... and 15 more

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dbarker]

The example is now tested here against three different yaml files covering all the default builders, extension builders, and composite sampler. These tests now fail on non-zero returns (thanks to the --test arg) or if the example logs an error.

[dbarker]

For smooth integration - this PR depends on several others and review/merge of these should be completed first:

1. [SDK] make global log level atomic #4368
2. [CONFIGURATION] validate and update config files to yaml schema 1.1.0 #4374
3. [CONFIGURATION] Build composable samplers from file configuration #4366

[dbarker]

The DLL build is not supported or tested for OTLP or Configuration classes (most are missing the required exports). Removing this to make the example easier to understand by moving the important config targets to the top of the file.

[dbarker]

The CompositeSampler was missing from the model and forced SamplerConfigurationVisitor to take on knowledge of composable samplers which are a different type (and class hierarchy) from top level samplers. This forced an anti-pattern in the SdkBuilder where the SamplerBuilder visitor repeated the same implementation for each composable sampler override and the ComposableSamplerBuilder visitor had to override methods for the top level (non-composable) samplers to throw an error. Additionally it forced the SdkBuilder to provide create methods for each composable sampler.

The fix is to make the CompositeSampler a formal model component that owns a composable sampler config, create a builder interface for it (added to the registry), and separate the sampler and composable sampler visitors.

[dbarker]

@marcalff

I'm happy with the content of this PR and test coverage, but realize it has grown a bit and changes a lot especially after the sampler/composable sampler visitor refactor and adding CompositeSampler to the model (see discussion_r3744253342).

For context, this PR is step 2 from #4352 and the goal is to instantiate all the sdk component builders in separate trace, logs, metrics builders libraries then use the registered builders in the SdkBuilder. This breaks many direct dependencies on the signal libraries, just leaving the provider level dependencies in the SdkBuilder that will be addressed in step 3.

I'm interested in your feedback on the overall design and desired scope for review.

Questions:

1. Any concerns with the high level changes in the PR?
   • Creating CompositeSampler as a formal model component with its own builder in the registry, and the separation of sampler and composable sampler visitors.
   • Adding a ReigstryFactory and changing the Registry to be empty on construction, which is a breaking change.
2. Do you have a preference on scope of review?

   • I can break this into smaller PRs if that would help. A alternative to this one PR may be:

     • PR 1: Add CompositeSampler model and builder to the registry and update tests
       • New interface and visitor classes
       • Update registry and tests
     • PR 2: Trace builders
       • Break out sdk trace builder components from SdkBuilder to the new trace_builders component
       • Use the ComposableSamplerConfigurationVisitor (and update all impacted files)
       • Update SdkBuilder to use builders from the registry for all trace components (except the provider)
       • Add the registry factory and use it in the tests and examples
     • PR 3: Logs builders
       • Break out sdk log builder components from SdkBuilder to the new logs_builders component
     • PR 4: Metrics builders
       • Break out sdk metrics builder components from SdkBuilder to the new metrics_builders component

     Note: PR 2 will still be a big one but needs to occur in one merge to avoid drift with the SdkBuilder. PRs 3 and 4 are fairly narrow after that.

Happy to adjust. I just want to make sure the direction is right before going further.