[ci] run the uss-qualifier as part of the CI

[Shastick]

To increase test coverage, we add a step to the CI that will run the qualifier against the DSS version built from the current PR.

Notes:

• this currently only runs "single instance tests", as, to the best of my understanding, only a single DSS instance is started in CI (therefore, only a single DSS is configured)
• this does not run any CRDB-specific checks (they are skipped)
• the configuration was obtained by running the qualifier with the --config-output option, with the following modifications:
  • removal of the second DSS
  • add has_private_address: true to dss resource specifications (otherwise the qualifier fails on resource initialisation)
  • set uss1: all_astm_dss_requirements in the participant_requirements artifacts section

Test plan:
This worked both locally when running the qualifier from a docker image built from a recent release of the interuss/monitoring image, and passes on the CI when running with the monitoring release v0.8.0

See this successful test run for example

[BenjaminPelletier]

We certainly want to pin our dependencies -- not pinning means that any change in a dependency can break our system without any change in our system.

[BenjaminPelletier]

The ability to bring up a local DSS instance should certainly exist in the DSS repo -- we shouldn't need to rely on the content of another repository to do that.

Since uss_qualifier is designed to test systems however they're deployed, we should tell it how our DSS system is deployed when we want to test it. That means we should have a test configuration for testing the DSS tracked in this repo. The configuration will probably look a lot like this one, but we should remove the $refs because the targets exist in another repo and we don't want to be dependent on them for the configuration to be valid. To do this, we can run uss_qualifier with --config-output.

Once we have a locally-deployed system to test and a configuration specifying how to test it, we should be able to just run uss_qualifier directly similar to how we run prober directly. monitoring's run_locally.sh is probably a good hint on what that command to run uss_qualifier should look like, but we shouldn't need to run the script in the other repo since that's just an example and not the generally-expected usage of uss-qualifier.

It is probably also a good idea to (separately) modernize the local DSS deployment approach in this repo to look more like the one in the monitoring repo, but the two repos should not be directly coupled.

[BenjaminPelletier]

We should be using uss_qualifier as a standalone tool that is released separately from the DSS. When this is the case, we should simply be able to use the released monitoring docker image (like the prober check does) and not check out the repo at all. If we really need to use a specific commit of that repo that is not released, that probably indicates a problem in our release strategy since if this user needs that specific unreleased commit, it's likely others will want to use that specific unreleased commit as well, so we should make a monitoring release that includes that commit.

[BenjaminPelletier]

Most of these configurations are not valid for testing the behavior of the DSS product itself. A configuration very similar to dss_probing in the monitoring repo should be all we need to verify compliance of this DSS implementation to relevant requirements. If that test suite is missing tests to adequately verify compliance of a DSS implementation, we should add those missing tests to it rather than relying on other test suites not directly testing a DSS implementation to incidentally cover those tests.

[Shastick]

The step is run and succeeded.