declarative config : configure EDOT

[SylvainJuge]

This issue aims to track progress on adding support for declarative configuration in EDOT Java, the implementation will be split into multipe PRs.

This list has been initially created by reviewing what is being done in ElasticAutoConfigurationCustomizerProvider for automatic configuration.

• override default telemetry.distro.name and telemetry.distro.version declarative config: set distro + user-agent #1050
• add user-agent customization declarative config: set distro + user-agent #1050
• add ability to skip server certificate verification
  • there is no way to call setSslContext with declarative config, so we have to contribute this upstream
• enable experimental runtime telemetry
  • decl. config. enable experimental runtime metrics #1056
  • jvm.buffer.{memory.used,memory.limit,count}
  • jvm.system.cpu.{load_1m,utilization} (used in runtime dashboard)
  • jvm.memory.init
• configure resource providers (deployment.environment copied to deployment.environment.name)
• configure delta metrics temporality
  • decl. config: delta metrics temporality #1058 initial attempt with 'magic' behavior
  • declarative config metrics delta #1062 set delta metrics temporality with explicit declarative config
• configure span stacktrace capture declarative config: indy, propagator, stack trace, sampler #1067
• configure default sampler declarative config: indy, propagator, stack trace, sampler #1067
• configure indy enabled by default declarative config: indy, propagator, stack trace, sampler #1067
• switch to alternative approach to avoid "magic" configuration: switch alternative approach to declarative config #1060
• universal profiling integration
• inferred spans
• doc/example: configure baggage to span attributes (opt-in)
• doc/example: configure http/messaging span filtering (opt-in), this allows to fix selectively ignore HTTP spans + configure it with declarative configuration #826 and Selectively ignore message queues #909

Open questions/ideas

• we can now easily print resulting config in json/yaml, should we use that instead for debug logging ?
  • might be easier to use than what we currently have (which also include all the defaults, whereas here we should have what has been explicitly set + what is modified/added by EDOT).
  • if we add this upstream it would allow an easy diff of the effective differences in behavior between the two implementations: for example if we replace a sampler, all the extensions that we explicitly configure, ...
• for cloud resource providers enabled by default, we might want to switch to suggest that in the "default" declarative configuration to have them by default, which then allows users to opt-out when needed. We can't distinguish from "nothing is explicitly set" and "user disabled all providers" as we get an empty array in both cases.
  • Update: there are numerous resource detectors that we must include by default, we do that by adding it to the "onboarding configuration" and then let users disable it as-needed.