Generate certificates in unit-test fixtures to fix parallel test execution

[jschmidt-icinga]

Description

Currently in master, parallel test execution is broken, because the tests that need TLS certificates overwrite each other's certificate files in the middle of tests. This PR fixes parallel test execution by generating CTest fixture units to set up each certificate once for all tests that require it and using CTest's dependency resolution to run those units before the actual tests.

Implementation

A new unit-test decorator RequiresCertificate is added that can be constructed with a list of certificates that this test requires and a prefix domain the test belongs to. Tests from different prefix domains are not run in parallel with each other and a cleanup will be performed in between the groups.

On instantiation, this decorator will add CTest fixtures for the setup and cleanup of the CA and required certificates (if no other test has added them yet). CTest fixtures are themselves test-units that are put into a dependency relationship with their associated test-cases by CTest and it is ensured that the setup routine runs before all tests that require the fixture and the cleanup routine runs after these tests. The fixtures are shared by all tests that require the same certificates with the same prefix.

The old prepare_directory_* and cleanup_certs tests that made up the ssl_certs fixture were removed in favor of these new fixtures. And the CertificateFixture Boost.Test fixture (which gets run once per test) no longer does any setup and cleanup on its own. All it does now is copy the certificates from the persistent directory to the local test directory, which has been prefixed with a UUID to make it unique between tests.

Rationale

The generation of the fixture units is fairly complex for currently not a lot of (current) usage, but it is a general proper solution, unlike the increasingly ugly workarounds that the lazy generation of certificates and manually added ssl_certs_* fixtures that do much other than enforce ordering between the tests. Recently I attempted to fix another problem this caused in #10749, which added more workarounds, but I should have gone with this solution instead.

Parallel execution of tests is the default on for example the build scripts of Gentoo and maybe other distros and our CI could also benefit from it. See below for a comparison of serialized vs parallel test execution. Just requiring downstream to turn off parallel testing because our tests break with it would also not be a good look so this fixes it to run as much in parallel as possible.

Before

$ ctest --parallel --output-on-failure
<various errors>
$ ctest --output-on-failure
[...]
Total Test time (real) =  12.80 sec

After

$ ctest --parallel --output-on-failure
[...]
Total Test time (real) =   3.53 sec

Other Changes

Since I was editing those lines anyway I also added the network label to the http unit-tests which fixes #10722.

[yhabteab]

Too much low-level boost test framework stuff, but seems to just work fine. I've left just some nitpicking comments, but overall I don't see any major issues. However, why aren't the GHA tests running in parallel now? Instead of postponing that change into the future, I think we should just do it now, as it could help us catch some issues not triggered on my/your local machine.

[jschmidt-icinga]

However, why aren't the GHA tests running in parallel now? Instead of postponing that change into the future, I think we should just do it now, as it could help us catch some issues not triggered on my/your local machine.

Agreed. I'll add a commit to change the GHAs and ContainerImage to use the parallel tests.

[jschmidt-icinga]

• Fixed the formatting mistakes and requested minor changes.
• Now uses ctest --parallel --output-on-failure on Linux and Windows GHAs and on the ContainerImage build. Let's see if it works properly on all targets.

Too much low-level boost test framework stuff

I agree, but it's supported low-level functionality that hasn't changed in ages, so the added maintenance burden should be minimal. And registering test-cases programmatically is something every modern C++ unit-test framework has, so migrating to a different one (like doctest or catch2 for example) should be as easy as switching out the function calls to register the new test cases. Many even have an identical syntax to add decorators.

[jschmidt-icinga]

I've given up on enabling and fixing the parallel builds for the Container Image for now and will do that in a separate PR so we can review and possibly merge this in the meantime.

[yhabteab]

Shouldn't this PR also fix #10722?