Implement default type fallback

[SylvainJuge]

What does this PR do?

Implements elastic/apm#602

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

[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: 2022-04-04T08:26:05.554+0000

• Duration: 53 min 19 sec

Test stats 🧪

Test	Results
Failed	0
Passed	2843
Skipped	20
Total	2863

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

[github-actions]

/test

[eyalkoren]

[minor] proposal - do that in a base implementation for beforeEnd() instead and call super.beforeEnd() in children

[SylvainJuge]

I suggest to do it without any sub-classing: by moving the type attribute directly into AbstractSpan, while the field value has different semantics in Transaction and Span this makes sense and allows to keep this normalization private in AbstractSpan.

I'll push an implementation of this in this PR, let me know if that would be a good fit here.

[eyalkoren]

Not sure. Why was it in the subclass in the first place? Is it because of the volatility requirement in case of transactions and not in case of spans (not sure why)? Maybe there was a reason for this separation.
I assumed it was in the base class when proposing that

[SylvainJuge]

I really don't know why it was like this in the first place, doing some git archaeology it has been like this since 2018.
Maybe @felixbarny remember something about having two distinct fields and one of them being volatile, as this is not urgent we can definitely discuss this during next weekly meeting.