declarative configuration support : universal profiling integration

[SylvainJuge]

things to refine/clarify

• should we provide this as a standalone extension to make it usable with upstream distribution ?
  • answer: we already provide it, it does not supports declarative config though
• should we start creating an upstream implementation in java contrib and make it compatible with the upstream profiling if available ? If yes, then it could also answer the question above and provide a better "upstream first" implementation.
  • upstream implementation is not there yet for correlation: 🏆 Epic: OTel API/SDK Integration open-telemetry/opentelemetry-ebpf-instrumentation#1140
  • answer: this might take a while, so we will keep this as-is
• the current implementation requires to wrap the exporter for host.id correlation with data from the profiler, we need to ensure we can do the same with DC
  • maybe providing a "good example for declarative config" + checking at runtime the UP span processor is in the expected order.
  • answer 1: there is more than just host.id
  • answer 2: (copied from discussion with @JonasKunz)
    • The processor buffers root spans to wait for correlation data from the profiler to come in. Only after the correlation data is there, we attach that data to the span and then send it.
    • So the wrapping does need to happen. It doesn't need to happen in the span processor though, it could also be done in a SpanExporter if that is easier to achieve.
    • maybe even better: We could make the universal correlation span processor a replacement for the batching span processor. E.g. it performs the task of the batching span processor, but in addition can buffer / hold back the spans it needs to buffer.
    • That probably would be easiest from declarative config perspective
    • So it would properly be best to keep the implementation as a wrapper around BatchingSpanProcessor. However, from the configuration surface it would take all the config options a BatchingSpanProcessor gets and then construct it's delegate itself in code

tasks

• migrate universal profiling to declarative configuration + test it on EDOT
  • experiment: verify that we can wrap the batch span exporter transparently using a custom exporter and still make it provide all the features of batch span exporter.
  • if experiment is successful, then proceed to implementation.
• add universal profiling to default declarative configuration