This spawns a mutter WM for the xvfb instance and wraps it in its own
dbus session.

Also use a larger screen size (1080p) - mostly so we can check the
testuite runs with differently sized screens, but alspo because that's
today's default screen size.

This exposes the issue from #4136 in the testsuite.

Duplicate the X11 testsuite into x11full and x11bare.
Run both of them in the Fedora CI runner.

For now they do the same thing (followup commits will change that), but
the goal is to have 2 testruns:

x11full should get as close to simulating a modern full-featured setup
with a compositing WM and all extensions.

x11bare should have the minimum required setup that te testsuite needs,
but nothing more. No compositor, a WM wit the minimal set of features,
etc.

This is supposed to test the most fallback GL stuff, so we might want to
set even more env vars here.

Also enable the run for the Fedora builder in CI.

Printing these out breaks TAP output, and we really
aren't interested in them.

Otherwise leaks could be missed.

This may help with the sporadic "No display" failures
we are seeing when running tests under X11 in ci.

Now that we have something that is both reliable and local.

Turning it off didn't fix the crashes; and we allow
the asan build to fail anyway now. And the leak reports
are useful whenever it doesn't crash.

When running our test suite on our CI infrastructure.

The leak sanitizer causes on average 3-4 tests
to segfault during a testsuite run. Disable it
for now to see if we can get a successful
testsuite run with asan alone.

When running the testsuite with the address sanitizer,
many of our dependencies cause it to report cause it
to report memory leaks, causing tests to fail.
Therefore, point the leak sanitizer at a list of
suppressions. The list is kept in the lsan.supp
file in git.

In my local testing i was burned by the default 300sec value here.
I'm not sure if we actually hit this in the CI, but lets not
take any chances.

The test setup mechanism in meson is not flexible
enough to let us run different suites depending
on setup, so just pass in explicitly which suites
we want to skip, depending on the backend.

We want the test names in the junit xml to be
unique across all the tests in a job, so we need
to include the backend in the test name.

And we also want to see the used backend in
the html report.

These need some more work, so ignore them for now,
to get the initial multi-backend testsuite into
production.

Run the testsuite under x11, wayland and broadway
in the fedora-x86_64 job. This requires us to use
the v17 image which includes weston.

The report is relative to the build directory, and so are the generated
assets.

We are going to need to hide the report generation into the test runner
script, as we want the job to produce the reports even in case of
failure, instead of bailing out immediately.

Otherwise we're going to run the accessibility test suite, and it's
going to fail.

We should have a single job for building both static and shared
versions of GTK. On the other hand, having a separate job for the
release build would be a plus.

Additionally, we shouldn't use an opaque script to build GTK; the only
step in the process that requires hand-holding is running the tests
suites under Xvfb, and having the build options visible from the YAML
file gives us a better idea of what kind of build we're running.