remove apmint

[florianl]

The apmint feature, currently implemented as an interpreter, was designed to correlate Profiling data with APM information using a vendor-specific protocol for data sharing between the profiler and an instrumented Java SDK.

However, two proposed OpenTelemetry specifications (PR 4719 and PR 4855), which are already partially implemented, aim to achieve the same goal of sharing correlation data across OTel signals.

Since an OTel-agnostic solution now exists as a replacement for its functionality, apmint should be removed.

[christos68k]

We should not remove this yet, instead once the OTEPs for process and thread context are approved we can have apmint be based on them instead.

[florianl]

As apmint is not adapted in the OTel community, I don't see a benefit to keep it. For the implementation of the OTEPs, like open-telemetry/opentelemetry-specification#4719, apmint can still be an inspiration as it is not lost with its removal. It will stay in the git history but will remove complexity and technical debt from the code base to maintain.

[christos68k]

It's still the only working implementation of TLS-based data propagation that exists for now. Once we can move to an equivalent alternative, we'll rework or remove it.

EDIT: To avoid wasting people's time (that could have otherwise opened a PR to do this), I am not going to merge a PR removing apmint until we have an alternative.

[florianl]

With the current apmint implementation there are various issues:

• if the custom APM library process block is not yet initialized by the time the respective process is handled by ebpf-profiler, then the initalization will fail and never retry
• apmint does not work with musl/alpine
• apmint does not implement the profiler registration message as required by the specification

[christos68k]

I discussed this with @florianl today, for more context my reasons for wanting to keep apmint until we can rework / replace it are:

• It serves as proof-of-concept for users that are interested in looking at a working implementation.
• Having it in the codebase makes my life easier as a maintainer, as I can identify issues like the recently discussed traceID/spanID fidelity/priority quicker, and have a basis for exploring solutions.
• It can act as a placeholder for proposals/OTEPs currently under discussion. It makes reviewing such, easier.