We use jstestnode

Using slapos.cookbook:wrappper is easier

was dead code

For now, we are just using this software to install firefox and xvfb,
but the instance is never used, we use jstestnode instead.

replace slapos.recipe:xvfb by a simple wrapper

and stop using xvfb recipe in favour of a simple wrapper

Update the patch not to use $TMPDIR, but to use an environment variable
dedicated for this purpose, because $TMPDIR has a different meaning.

With firefox 60, running `TMPDIR=/same/tmpdir/as/xvfb firefox --marionette` no
longer work and complains:

 Gtk-WARNING **: cannot open display: :0

If we investigate with strace we can see that marionette restarts with a
different $TMPDIR ( to store temporary files in another directory ) and we can see:

 connect(15, {sa_family=AF_UNIX, sun_path=@"/srv/slapgrid/slappart8/tmp/inst/TestRemoteDriver-0/tmp/Temp-0336e727-3485-4774-a816-75fda1baca12/.X11-unix"}, 113) = -1 EINVAL (Invalid argument)
 write(2, "\n(/srv/slapgrid/slappart8/tmp/soft/c5be5b0096cd286c70df5156590cf4f6/parts/firefox-60/firefox:29812): Gtk-\33[1;33mWARNING\33[0m **: cannot open display: :0\n", 152) = 152

To prevent this kind of problems, instead of using TMPDIR, use
a new dedicated environment variable XORG_LOCK_DIR.

No backward compatibility is provided, the profiles will be updated. In the
worst cases, non updated profiles will use /tmp/ and will work unless $DISPLAY
conflicts.

Instead of relying on slapos.cookbook:certificate_authority recipe, which
stops buildout processing, extract the minimal implementation to runtime
key/certificate validator and reject slaves, which does not pass this test.

This commits results in TODO item being done.

As slave requester is able to enter any string in server-alias validate it
against being correct domain name and in case if validation fails reject that
slave.

Also use a trick to have access to global slave state, see
https://fabianlee.org/2016/10/18/saltstack-setting-a-jinja2-variable-from-an-inner-block-scope/

Install validators dependency, which is a way to easily check if email is an
email or domain is correct.

As slave requester is able to enter any string in custom domain validate it
against being correct domain name and in case if validation fails reject that
slave.

Create caddyprofiledeps egg with dummy noop recipe.

Thanks to setting dependencies of this egg and enabling it on the instance
profile, buildout will install eggs during software run and activate them
during instance run.

No existing egg (like slapos.cookbook) is used, as this technique is to allow
profile/software release developer to choose required eggs used during
instantiation.

Another apporach would be to add dependency for validators in
slapos.recipe.template (in install_requires).

Thank to escaping whole command-line it is possible to process buildout
dangerous strings, like ${section:option}, pass them to the wrapper,
instead of killing the whole profile processing.

If the value does not contain "," drop its contents instead of stopping
processing of the whole profile.

Instead of needlessly storing information in configuration section, pass it
via jinja2 parameter. This is safe, in case if extra_slave_instance_list
would contain value like ${section:option}.

Mainly to fix parallel build.

https://wiki.saucelabs.com/display/DOCS/Test+Configuration+Options#TestConfigurationOptions-MaximumTestDuration

There is a way to pass monitor port to each replicated frontend by using
frontend-config-N-monitor-httpd-port, thus there is no need to pass through
the default value, as it comes default on each replicated slave.

I noticed by accident that tests for `software/wendelin/software-dev.cfg` where failing because buildout was picking eggs:

```
Installing eggs.
While:
  Installing eggs.
  Getting distribution for 'scikit-learn'.
Error: Picked: scikit-learn = 0.19.2
Failed to run buildout profile in directory '/srv/slapgrid/slappart7/srv/testnode/acv/soft/78ae8a6d8b0639addb22de2c7c96af63'
```

Turned out it was a problem with usage of `zc.recipe.egg:develop`

There was also a problem which `${gcc-fortran:}` that does not exist anymore.

/reviewed-on nexedi/slapos!395

Turned out we are not ready to apply the part about storing wrappers in
${bin:directory} from "Firefox: install wrappers in
${buildout:bin-directory} and version up"

This commit is to be reverted once we update test nodes to 1.0.73 or
higher

Slapos compatible wrapper is no longer installed in `parts/firefox/firefox-slapos` , but directly as `firefox` in the `${buildout:bin-directory}` of the software. `geckodriver` is also in the same directory.

Firefox version up to 52.9.0esr

Geckodriver version up to 0.17.0


/reviewed-on nexedi/slapos!387

:develop is a bit special in that it does not install the egg, but just
tell buildout that this directory contain the egg, so that recipes that
will install this egg later will pick the develop-eggs.

  Allow the KVM software release request a disk via plugin,
  if the plugin is enabled the chown will be set to give the disk to the partition.

Not released yet functionality for regular expression cookie rewriting
is available: https://github.com/mholt/caddy/pull/2144