[META] Dynamic capabilities phase 1

[jackshirazi]

Implement the following configurations:

Higher Priority for dynamic config

• DONE: Disable instrumentations
• DONE: Sampling - already available but not dynamic
• DONE: Disable ALL instrumentations
• DONE: Change log level dynamically

Medium priority for dynamic config

• DONE: Profiling inferred spans - done but not dynamic, can be made dynamic
• Trace methods (start without wildcard support) (will be done as a separate outcome)

Low priority for dynamic config

• Capture body
• Application packages
• Sanitize field names
• DONE: Disable agent config
• DONE: Disable Send & Context Propagation Only - DONE the dynamic sending part but not the central config part

Not a priority for dynamic config

• Transaction name groups & Use path as transaction name (should be done as an OTel collector processor pipeline)
• Don't verify the server cert
• DONE: Global Labels - not dynamic in classic agent, so no need to be dynamic in EDOT. It's already present in EDOT as static config

Open Question

• Enable log correlation
• Capture JMX metrics

All of this work assumes we'll use central config

Upstream contribution

• Supports External Control of Agent Behavior Dynamically open-telemetry/opentelemetry-java-instrumentation#12251

[jackshirazi]

For 9.1 we have

[SergeyKleyman]

@jackshirazi

1. Is recording option the same as Disable agent config mentioned in the top comment?
2. The description for recording option mentions Elastic APM.

[jackshirazi]

Thanks @SergeyKleyman having recording included looks like a bug, we're not actually supporting that. Just the EDOT java agent wasn't excluded from it - hence it's been included from the classic agent side. I'll raise a PR to fix that

[jackshirazi]

For 9.2 we'll aim to add sampling, trace methods, inferred spans, and polling interval to the kibana UI, and have an agent which manages those by the 9.2 release

[AlexanderWert]

trace methods will be done as a separate outcome