[run-tests.sh] simpletest_phpunit_xml_filepath() depends on public:// stream wrapper

This fixes the issue for me locally.

How to reproduce/test:

$ php core\scripts\run-tests.sh --php php --url http://drupal8.test/ --sqlite test/test.sqlite --dburl sqlite://test/db.sqlite --class Drupal\Tests\Core\Extension\ThemeHandlerTest

One more tweak - adding $recursive = TRUE to mkdir('public://simpletest')

Alright, so here's the fundamental problem space + root cause:

The test runner needs a filesystem path to write to. Period.

Whether that is for PHPUnit XML result files, or for a --sqlite database, or for the --xml junit output, or anything else, doesn't matter. We need a writable filesystem path.

In HEAD, we're working around that problem by installing an entire Drupal site for the test runner. In turn, public://simpletest/ is available to the test runner, which means that it has a dedicated place to write to.

If there is no Drupal site for the test runner, then there is no "public files directory" (at all).

Along the same lines, simpletest_requirements() creates the (writable) /sites/simpletest base directory that holds the test site directories for each executed Simpletest test.

If Simpletest module is not installed, then that directory does not exist. The only reason the testbot did not complain is because the testbot not only operates a root user, but additionally performs a blatant chmod -rf 0777 ./* prior to executing run-tests.sh, which in turn means that the test runner has write access everywhere.

Whenever I'm using the new "headless" --sqlite + --dburl parameters on my local box, I'm specifying a writable path for all the things that need to be written by the test runner; e.g.:

$ rm -rf build
$ mkdir build
$ run-tests.sh \
  --sqlite build/test.sqlite \
  --dburl sqlite://localhost/build/db.sqlite \
  --xml build

However, (1) that doesn't address /sites/simpletest which happens to exist on my disk already, and (2) I'm running on Windows, so I generally face no file permission issues (much rather the opposite; a malformed test run would be able to delete tons of other filesystem data).

The existing patch here essentially retains public://simpletest/ as-is; i.e., for "headless" test runs the default directories of a Drupal site are assumed, even though there is no Drupal site. If you'd start from a completely clean slate, that would translate into:

# sites/default/files == build
# ./simpletest subdirectory is needed for verbose browser output.
# The permissions assume that the webserver system user is not in the same group as current user.
$ mkdir -p sites/default/files/simpletest
$ mkdir sites/simpletest
$ chmod -R 0777 sites/default/files
$ chmod 0777 sites/simpletest
$ run-tests.sh \
  --sqlite sites/default/files/test.sqlite \
  --dburl sqlite://localhost/sites/default/files/db.sqlite \
  --xml sites/default/files

Whichever way we go, we'll need at least these two writable filesystem locations. Since code relies on public://simpletest anyway already, we could just simply make the public files directory of the (assumed) default site that required writable directory.

The sites/simpletest directory is required in any case, because Drupal needs to detect that before Drupal is bootstrapped in any way.

FWIW, this problem space is not limited to the test runner + Simpletest. PHPUnit tests should have a dedicated filesystem location to be able to write to, too. Not only for test results, but also for dynamically generated test data - which is very common for PHPUnit tests normally; our PHPUnit tests in core just weren't able to do that yet, because they have no filesystem directory to write to.

Re-rolled against HEAD, additionally taking #10 into account.