project tests: capture output for SKIP and UNEXRUN cases into meson-test-run.xml

[jon-turney]

As observed in #15534 (comment) investigating CI result changes involving skipped tests is harder than it should be, because we don't record any information about those tests into the testlog.

Future work?

• The whole 'result is None' (sometimes) thing makes this code more complex than it needs to be. Maybe create an appropriate TestResult object instead in those cases?
• The XML log contains text which has GitHub ::group:: folding directives inside. This kind of indicates a confusion somewhere?
• Maybe the plaintext log is actually pretty useless now we're more intelligent about what we write to stdout? Or should just be a capture of that?
• I think there's now a formal schema for JUnit XML, so perhaps we should verify our output against that? Certainly, this would help check I've added properties in the right way.

[dcbaker]

The JUnit was (when I originally wrote it) validated against the JUnit 4 schema. I think there's a newer one now, and there have been changes since the code was written.

[jon-turney]

The JUnit was (when I originally wrote it) validated against the JUnit 4 schema. I think there's a newer one now, and there have been changes since the code was written.

Uh, this is my fault for giving this PR a bad title: this is about the XML log written by run_project_tests, not the the XML log written by 'meson test'.

There is indeed a schema conformance test for the JUnit XML output from 'meson test'.

[jon-turney]

• The whole 'result is None' (sometimes) thing makes this code more complex than it needs to be. Maybe create an appropriate TestResult object instead in those cases?

This seems more difficult than I guessed, so maybe it's not worth it...

• I think there's now a formal schema for JUnit XML, so perhaps we should verify our output against that? Certainly, this would help check I've added properties in the right way.

Unfortunately, it seems that xml.etree doesn't have schema validation. lxml can do that, so maybe changing to use that would be ok (since I don't think the "only python stdlib" applies to the testsuite)?

It also seems that I'd misunderstood the JUnit schema, and while that has arbitrary properties you can attach to a testsuite, there's nothing similar for individual testcases. So drop the bit that uses that to attach the meson.log file.