Add library version detection for parametric tests

[Kyle-Verhoog]

Description

As per title add version detection. This enables parametric tests to reuse the @released decorator used by other system tests.

It works by retrieving the real tracer version from the library being tested by reading the http headers of requests made to the test agent.

This enables tests to be merged prior to the release of a feature.

A more accurate approach is proposed in #1445

Reviewer checklist

• Check what scenarios are modified. If needed, add the relevant label (run-parametric-scenario, run-profiling-scenario...). If this PR modifies any system-tests internal, then add the run-all-scenarios label (more info).
• CI is green
  • If not, failing jobs are not related to this change (and you are 100% sure about this statement)
• if any of build-some-image label is present
  1. is the image labl have been updated ?
  2. just before merging, locally build and push the image to hub.docker.com

[Kyle-Verhoog]

Darn, there seems to be some kind of incompatibility with the Java library.

An alternative approach to getting the tracer version might be to add version checks in the Test Agent interface rather than trying to do a trace request prior to the test case starting. This approach would be less invasive to the test cases. I'm going to give that a try next.

[Kyle-Verhoog]

Switching to checking the version in the test agent interface seems to have worked. It does carry the caveat that the test is only skipped at the point that data is requested from the test agent. If there are any operations performed in the test case that the library doesn't support then the test might crash/fail before it can be skipped.

In the future we could have the factories of the test servers declare the version of the library that they install and use that version. The challenge there is detecting the version for dev/custom installations of libraries that run in CI/locally.

[pawelchcki]

LGTM - thanks Kyle! 🙇

[cbeauchesne]

thank's a lot @Kyle-Verhoog