PHPC-2064: Use register_shutdown_function to disable caching of skipif results

[alcaeus]

PHPC-2064
Replaces #1301

As is, using any logic in a SKIPIF block after a previous call to skip_if_not_clean leads to the tests not being skipped. This is due to PHP 8.1+ reading the nocache output and discarding any subsequent output. To resolve this, we can change disable_skipif_caching to register a shutdown function that disables caching by printing nocache to STDOUT. While this can lead to skip messages containing an extra nocache at the end, I believe this is preferable to SKIPIF logic being ignored. I also believe it's not worth adding any logic to not print anything if a previous check resulted in skip ... being printed.

[jmikola]

While this can lead to skip messages containing an extra nocache at the end, I believe this is preferable to SKIPIF logic being ignored

I assume that was written before you added this static sentinel value? I don't think we need to worry about duplicate "nocache" lines.

[alcaeus]

Not quite. Assuming one check exits with the message "skip this test does not work", the shutdown handler would still add "nocache" at the end, changing the message to "skip this test does not worknocache".

[jmikola]

Is it necessary to append nocache to an existing line to avoid a BORK if it were printed on its own line after a skip?

Sorry, it's been quite a while since I thought about any of this.

[alcaeus]

No, it's more of a side-effect of how things are done: our skip functions call exit('skip whatever'); without a trailing newline. The shutdown handler then prints "nocache" to the output, meaning that it will be appended to the end of whatever the previous skip functions printed. As the message doesn't have a trailing newline, it's appended in the same line.

Looking at run-tests.php again, I can see that the output of the skip file is run through trim before checking for "nocache", so we could even print a leading newline in the shutdown handler to avoid appending to a previously printed skip message. I'll take another look at that.