Introduce async profiler upgrade utility and upgrade to 1.8.7

[eyalkoren]

What does this PR do?

Introduces a JUnit utility for upgrading async profiler. The test class is disabled by default, and should be invoked manually when an upgrade is required.

In addition, async profiler is upgraded to version 1.8.7, and uses the newly introduced safemode setting option through system property.

Checklist

• I have updated CHANGELOG.asciidoc
• async profiler is upgraded to 1.8.7
• the agent sets the AsyncProfiler.safemode system property

[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: 2021-10-06T08:40:22.436+0000

• Duration: 58 min 47 sec

• Commit: 1592fff

Test stats 🧪

Test	Results
Failed	0
Passed	2417
Skipped	19
Total	2436

💚 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 test.

• run compatibility tests : Run the JDK Compatibility test.

• run integration tests : Run the APM-ITs.

[SylvainJuge]

I did not looked at the added unit test details, but what are the benefits over using a test disabled by default over the ./apm-agent-plugins/apm-profiling-plugin/update-binaries.sh shell script ? Having two ways to update the agent would likely be confusing.

[eyalkoren]

what are the benefits over using a test disabled by default over the ./apm-agent-plugins/apm-profiling-plugin/update-binaries.sh shell script ?

I actually didn't remember we had such 🤦‍♂️
If I did, I wouldn't bother. Now that it is implemented, benefits are:

• Readability
• Version verification after upgrade

Since I already spent this time, does it make sense to keep?

[SylvainJuge]

what are the benefits over using a test disabled by default over the ./apm-agent-plugins/apm-profiling-plugin/update-binaries.sh shell script ?

I actually didn't remember we had such man_facepalming If I did, I wouldn't bother. Now that it is implemented, benefits are:

• Readability
• Version verification after upgrade

Since I already spent this time, does it make sense to keep?

Let's keep the test version then, maybe instead of having a disabled test just a executable entry point so it's not reported as disabled/skipped in reports and it does not require any modification to execute.

[SylvainJuge]

[minor] might be worth having a build property to define the version, then reuse this in AsyncProfilerUpgrader to avoid any confusion. Or, maybe simpler if AsyncProfilerUpgrader would be able to extract the version from this dependency at runtimeand remove the AsyncProfilerUpgrader#TARGET_VERSION

[eyalkoren]

This is the Java API dependency, not the lib itself - you see its version is 1.8.3. We don't need to maintain this unless the API breaks