Factor out reference counting to explicit API

[raphw]

This change introduces an explicit API for reference counting to the tracer API. This avoids that plugins need to rely upon the WeakConcurrentProviderImpl which is part of agent-core.

This solution is a suggestion, and it can be solved differently. For example, it would be possible to add the SDK as a dependency to the tracer API and to integrate this functionality via the current WeakConcurrentProvider. Doing so, the ReferenceCounted interface could be placed in the SDK and reference counting could be exposed via the WeakConcurrentProvider. This would however make reference counting available via the SDK.

Personally, I would prefer the latter solution. If there is a legitimate reason for reference counting in the internal plugins, there are surely legitimate reasons to use them in user plugins. Also, users choose their own knives to cut themselves with, and code instrumentation is already rather advanced programming to begin with.

[github-actions]

👋 @raphw Thanks a lot for your contribution!

It may take some time before we review a PR, so even if you don’t see activity for some time, it does not mean that we have forgotten about it.

Every once in a while we go through a process of prioritization, after which we are focussing on the tasks that were planned for the upcoming milestone. The prioritization status is typically reflected through the PR labels. It could be pending triage, a candidate for a future milestone, or have a target milestone set to it.

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-06-05T07:56:48.022+0000

• Duration: 15 min 45 sec

❕ Flaky test report

No test was executed to be analysed.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run benchmark tests : Run the benchmark tests.

• run jdk compatibility tests : Run the JDK Compatibility tests.

• run integration tests : Run the Agent Integration tests.

• run end-to-end tests : Run the APM-ITs.

• run windows tests : Build & tests on windows.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[JonasKunz]

Personally, I would prefer the latter solution. If there is a legitimate reason for reference counting in the internal plugins, there are surely legitimate reasons to use them in user plugins. Also, users choose their own knives to cut themselves with, and code instrumentation is already rather advanced programming to begin with.

I think leaving out the reference counting form the SDK is better for now: External plugins are written either based on OpenTelemetry or our our public tracing API which both don't support reference counting / recycling. For external plugins we accept that we might produce higher GC load (due to spans being GCd) instead of burdening the complexity of ref-counting on the users.

[JonasKunz]

run elasticsearch-ci/docs