Replace/extend resource dest. with service target.{name.type}

[SylvainJuge]

What does this PR do?

Implements the agent-side migration from sending span.destination.service.resource to span.service.target.type + span.service.target.name.

Impacted features:

• dropped spans stats
• compressed spans
• User API ability to set a custom value for span.destination.service.resource
• migration of all usages of span.destination.service.resource

The agent remains backwards compatible with existing APM servers:

• only new fields are added to the protocol
• existing fields values are inferred from the new internal data structure.

Checklist

• This is an enhancement of existing features, or a new feature in existing plugins
  • I have updated CHANGELOG.asciidoc
  • I have added tests that prove my fix is effective or that my feature works
  • Added an API method or config option? Document in which version this will be introduced
  • I have made corresponding changes to the documentation
• add a new API entry point to set the span service type and name.
• add new fields to the existing resource destination JSON spec + back-port changes to upstream spec Span service target fields specification apm#627
• backport changes to JSON resource spec + OTel gherkin spec to upstream APM repo
• sync with state of upstream specification Span service target fields specification apm#627
• create follow-up PR in https://github.com/elastic/apm/ to enhance target fields values & destination resource for non-relational databases: MongoDB (already impl in this PR), Elasticsearch, ... Spec: enhance dependencies granularity for other backends/dependencies apm#646

[ghost]

💚 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: 2022-06-01T12:50:13.387+0000

• Duration: 50 min 38 sec

Test stats 🧪

Test	Results
Failed	0
Passed	2919
Skipped	22
Total	2941

💚 Flaky test report

Tests succeeded.

🤖 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!)

[eyalkoren]

Nice!

Several comments, nothing major.
I didn't go over all plugins because I saw that you used MockReporter#checkDestinationService to see that you didn't miss, but worth changing this flag and related methods to something like co.elastic.apm.agent.MockReporter#checkServiceTarget.
I did see that in many plugin tests you either replaced resource test with name and type, you didn't, but unless I am missing something, we should test both. If not - ignore.

[eyalkoren]

LGTM
I made a couple of suggestions for very small but very easy perf improvements.
In addition, there are some comments from the original review that were still not addressed, mainly if the null check in serializer is relevant and whether we want to keep todo in code rather than have a meta issue

[eyalkoren]

We should release not at the same day as the stack to make sure this didn't break cross-repo links

[eyalkoren]

Meant to approve and let you decide what to do with not yet addressed comments, just used the wrong checkbox 🙂

[SylvainJuge]

The comments should be fixed, I've opened elastic/apm#646 to enhance spec on other types of backends.