Patch the testbot to start both chrome in webdriver mode and phantomjs in non webdriver mode

Let's move towards using chrome instead ... its a real browser.

This patch doesn't work yet, but its a start

This was not the right patch, here comes the full diff.

Some work, xvfb at least starts now properly

Do we need xvfb? Chrome has a headless option, and seems to run great in replacement of PhantomJS

@mglaman
Yeah you are right, I started with xvfb but I think its not a requirement.

In https://www.drupal.org/node/2869424#comment-12222509

I ran

$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --headless -disable-gpu --remote-debugging-port=9222

Then

MINK_DRIVER_ARGS='["http:\/\/localhost:9222",null,"http:\/\/localhost:8080"]' MINK_DRIVER_CLASS='\DMore\ChromeDriver\ChromeDriver' ../bin/phpunit -c core --testsuite functional-javascript --stop-on-failure

Core's JS tests passed without issue. No xvfb, etc.

@mglaman
Yeah theoretically that would be it, but chrome doesn't just run in docker easily, see https://github.com/jessfraz/blog/blob/master/content/post/how-to-use-new...

There are various workarounds/fixes:

* Actually configure the seccomp profile of docker, which is not mall
* Run it with --no-sandbox, which feels okay for a testbot only environment?
* Run chrome with full sudo permissions

I'm now experimenting with option b)

Okay, so the testbot got some overhauls and changes. Here's where things are at right now:

1. There is a third container that contains chrome, and chromedriver, that is started alongside the mysql and php containers. (DOCKERFILE for the curious: http://cgit.drupalcode.org/drupalci_environments/tree/webdriver/chromedr...)

2. The testbot now starts all three containers, and creates a docker network between those containers, and now utilizes the hostnames of those containers to communicate. (as opposed to using http://localhost as the url).

3. when run-tests.sh is kicked off, the pertinent information about the chromedriver container is inserted into the environment variable to control the webdriver implementation. For example, the patch here: (https://www.drupal.org/project/drupal/issues/2775653#comment-12361069) is currently being re-ran and has the following command:

cd /var/www/html && sudo MINK_DRIVER_ARGS_WEBDRIVER='["chrome", {"browserName":"chrome","chromeOptions":{"args":["--disable-gpu","--headless"]}}, "http://chromedriver-jenkins-drupal-patches-39407:9515"]' -u www-data php /var/www/html/core/scripts/run-tests.sh --color --keep-results --concurrency "31" --types "Simpletest,PHPUnit-Unit,PHPUnit-Kernel,PHPUnit-Functional" --sqlite "/var/lib/drupalci/workdir/simpletest.standard/simpletest.sqlite" --dburl "mysql://drupaltestbot:drupaltestbotpw@172.18.0.4/jenkins_drupal_patches_39407" --url "http://php-apache-jenkins-drupal-patches-39407/subdirectory" --all

(we have to use the IP address for the database, because old timey docker networking sucks, and gethostbyaddr syscalls do not resolve the hostname properly, which is how mysql pdo connects).

So, this docker network stack/chromecontainer stuff is all a workaround until we can use that container as part of a docker compose workflow.

Thank you a lot @Mixologic!