Query apm server for version and details about supported features

[jaggederest]

What does this pull request do?

This adds a version method to the Config class, which internally checks the server for the value of it's version in the configuration data returned from the root url

Why is it important?

This will be used to gate some features based on server version, most directly elastic/apm#545

Checklist

• I have signed the Contributor License Agreement.
• My code follows the style guidelines of this project (See .rubocop.yml)
• I have rebased my changes on top of the latest main branch

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

• I have made corresponding changes to the documentation
• I have updated CHANGELOG.asciidoc
• I have updated supported-technologies.asciidoc
• Added an API method or config option? Document in which version this will be introduced

Related issues

Closes #1274

[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-03T09:19:12.110+0000

• Duration: 32 min 14 sec

Test stats 🧪

Test	Results
Failed	0
Passed	44393
Skipped	80
Total	44473

🤖 GitHub comments

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

• /test : Re-trigger the build.

• run benchmark tests : Run the benchmark test.

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

[ghost]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (1/1)	💚
Files	99.213% (126/127)	👍 0.006
Classes	99.213% (126/127)	👍 0.006
Lines	59.678% (2519/4221)	👎 -0.027
Conditionals	100.0% (0/0)	💚

[estolfo]

Looks good!
We should think about whether we want to get the version lazily or explicitly at agent start.

[estolfo]

And just a reminder to put this into non-Draft mode to signal that your work is complete on it.

[felixbarny]

We should think about whether we want to get the version lazily or explicitly at agent start.

Ideally, querying the version should not block both the application startup and the agent startup. In other words, it's fine if the agent starts creating transactions and we only know about the server version some time later.