[meta] Create functional tests of run command output to test production essentials

Beginning to make a framework for functional tests here: #2683013: Better functional test framework

Once that's in, we can move forward on these cases.

#2680713: Handle missing @groups has a test now.

I've been doing some work on this and I think progress has been made.

Writing some thoughts here while reviewing the code ... so there is some review, and some 'future work' items mixed in this comment. I recognize that some (or all?) of these are tangential to this issue, but wanted to make sure I captured them without needing to do a full context switch.

1. Usability quirk:

* This test base class will always use config:load to load the blank configset.
* You then specify DCI_* config values by overriding self::$dciConfig.

A side effect of this is that running the tests locally overrides your local configuration, which can lead to a bit of a 'wtf' moment the first time it's encountered. I think the test run should leave the system in it's original state once it's done running; so we should add a followup issue to enhance this to save/restore the existing configset. (TODO: Create issue)

2. Test configuration approach:

* DCI_* configuration for this test run.
* Override this array with your own config sets and settings.

Another option for this may be to create each of the functional test configurations as configsets of their own (rather than hard-coded fixtures within the class) and use the config:load command to pull up each combination for a test ... these configs could then serve a dual purpose; first for testing, and second as 'example' configs that devs can use as a base to clone/modify/extend for their own configs.
(TODO: Create issue)

3. Test Output: The test output (as displayed in PHPStorm, for example) could use more verbosity, especially for any 'intentional failure' test cases which bail early ... the output for these cases consists of two 'cloning statements' and nothing else. #2725495: Add display_errors to phpunit.xml

4. Scenario Coverage: I updated the list in the issue summary with the applicable test names.

5. Test modules: The tests use a combination of legit, published projects and user-namespaced sandboxes, both of which increase the risk of fragility ... not only due to the risk of code changes within the repo, but also because there is no way to know that those projects/users/etc. are being used in this way from the perspective when looking at those projects/users from a perspective outside of this project. One suggestion would be to create a namespaced user on drupal.org, and generate lightweight namespaced projects/sandboxes providing each of the dependent configurations as needed under that specific user account.

6. Git clones for every test: Ryan and I discussed this briefly at NOLA, and Mile23 expressed this as a concern as well in a comment on the "missing @groups" issue (#2680713-12: Handle missing @groups). This could use a big chunk of optimization.

7. Test description cut and paste issues:
SimpletestPatchFailTest contains the description for ContribNoTestsTest.
SimpletestPhpFatalTest contains the description for ContribNoTestsTest.
CoreNoGroupTest contains the description for CorePatchAppliedTest.

8. Duplication: I don't see a need for both 'PatchFailTest' and 'SimpletestPatchFailTest', which appear to do the same thing.

9. Run a failing core test against a single test class: Not related to the code, but more the issue summary. Ideally, it should be hard to find a commit hash where core has a failing test. ;) This could be done easier in contrib, especially if we adopt the approach suggested in #5.

Bouncing back to 'Needs Work' for #7 and #8 in this list ... otherwise, RTBC.

Fixed the comment changes and removed the duplicate test. Other than the test removal, no other functional changes made ... so I think this is good to go.

Reviewing 2680565-Create-functional-tests-of-run-command-output-to-test-production-essentials branch.

Some tests need depend on containers, updated TESTING.md to reflect this.

Removed out-of-scope changes to RunCommand.

Added @todo about timing code in JobResults.

Removed TaskInterface because that's the step after the tests are done. :-)

CoreD8PassingTest called setUp() for some reason I didn't understand, so I removed that.

CorePatchAppliedTest had a scaffold fwrite(), removed.

Marking this as RTBC so @Mixologic can push back as needed.

Pushed changes from 2680565-Create-functional-tests-of-run-command-output-to-test-production-essentials branch to dev.

Leaving the issue open so we can continue adding tests.

At one point, the TESTING.md file states that you need to execute composer install. It seems like that composer has not been installed globally. Therefore we need to execute /home/vagrant/drupalci_testbot/composer.phar install instead.

Well spotted. :-)

Added to dev branch.

         // Re-run drupalci init to pick more images.
         $ cd /tmp
         $ git clone https://git.drupal.org/project/drupal.git
+        // Install dependencies for Drupal
         $ cd /tmp/drupal
-        $ composer install
+        $ ~/drupalci_testbot/composer.phar install
         $ cd ~/drupalci_testbot
         // Remove existing containers.
         $ ./drupalci docker-rm containers

Made a spreadsheet of tests here:

https://docs.google.com/spreadsheets/d/1EOXvbC2ir-J7VVxUrnR1xpWePArTr7Gu...

I've created a new sandbox project in order to test the syntax errors. You can find it here.

Converting this to a meta.