yaml jmx metrics test infrastructure

[SylvainJuge]

This PR adds test infrastructure coded needed to make testing YAML metrics easier.

This has been extracted from #13392 to allow reusing it and making review easier.

Related PR(s) that depend on it and provide use-cases:

• jmx add jvm metrics yaml #13392
• Jmx unit semconv alignment - Tomcat #13650

The test assertions partially overlap the ones provided by SDK testing library but I think it's an acceptable compromise for now as it makes importing/reusing yaml files from contrib easier for the migration process.

For more technical details here is a copy of my conclusion on the topic (initially posted here as comment)

I tried to refactor the test assertions to only rely on the ones provided by the SDK (using io.opentelemetry.sdk.testing.assertj.MetricAssert), but this requires quite significant work which is probably not worth the investment time for now.

• the protobuf parsing logic can be reused from io.opentelemetry.javaagent.testing.common.AgentTestingExporterAccess but needs to be moved to a separate class to prevent classloading issues.
• the metric type checks like isCounter and isGauge needs to be adapted to fit both long and double variants, for example with isLongCounter and isDoubleCounter

Overall I think it would be more beneficial if we extend the SDK MetricAssert with similar "high level" assertions that are closer to the metric data model in order to help making test code more readable. For example, currently writing test code for an updowncounter requires to know that it is stored as a "non monotonic sum" and that a counter is translated to a "monotonic sum", both of which require to read the actual values as the monoticity is not preserved when parsing it from protobuf to MetricData.

[SylvainJuge]

[for reviewer] copied as-is from contrib: https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/jmx-scraper/src/integrationTest/java/io/opentelemetry/contrib/jmxscraper/target_systems/MetricsVerifier.java

[SylvainJuge]

[for reviewer] using a very close test setup as in contrib: the target system is started with the instrumentation agent and a copy of yaml definitions to test them, a very simple metrics exporter endpoint is used on the test host to collect the metrics from the remote system. We could maybe reuse this in other tests but it would probably be better in a separate PR for simplicity.

[SylvainJuge]

[for reviewer] this has been copied as-is from contrib with a small rename https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/jmx-scraper/src/integrationTest/java/io/opentelemetry/contrib/jmxscraper/assertions/Assertions.java, it would make sense to add those assertions to io.opentelemetry.sdk.testing.assertj.OpenTelemetryAssertions but the latter is in the SDK, works with MetricData and not directly with the io.opentelemetry.proto.metrics.v1.Metric class.

[SylvainJuge]

[for reviewer] this ensures that the test explicitly tests all the common properties of JMX metrics, which could be a feature that would be removed if we used io.opentelemetry.sdk.testing.assertj.MetricAssert, however this also means some duplicated effort so it could make sense to reuse what is available.

[SylvainJuge]

We now have two distinct PRs that depend on this test code, so we should be ready for review:

• JVM metrics: jmx add jvm metrics yaml #13392
• Tomcat metrics: Jmx unit semconv alignment - Tomcat #13650

Once this is merged, it would help unblock those PRs and make each PR review easier, for example in the JVM metrics case ~75% of the PR is included in this PR.