This disable a theia security feature of using a different hostname for
each webview. By defaut, for each webview, thiea generate an unique
hostname that when using vifib frontends would be something like
https://uuid.webview.softinstXXX.host.vifib.net but that's not usable in
our case because we cannot create frontends for a subdomain (also we
don't have certificates for such domain).

Configure THEIA_WEBVIEW_EXTERNAL_ENDPOINT to something less secure, but
working in our environment. This fixes embedded jupyter notebooks and
other web views.

This reverts commit 7e3bc5ee.

Theia does not seem to be ready for this version, several things are not
working:
 - selecting another python interpreter
 - linting in the editor
 - at startup there's always a "Python is not installed.Please download
and install Python before using the extension." warning . I think this
happened sometimes with the previous version too.

jedi was working fine, but too maybe critical features are broken.

fixes 794185d0

Otherwise it's installed by python setup.py outside of buildout

This is partially WIP but I let @jerome, @Nicolas and @tomo to review it. 

Thie WIP is resilient tests included on it, it may cause the test runs for several hours.

My current idea is release all except resilient one, them use the Test case as a Library and recreate additional folders/softwares, which will run resilient tests. 

It still required to see if we can optimise the compilation maximazing the use of shared.

See merge request !748

This MR is a complement of nexedi/slapos.core!214, however it can be merged before the release of slapos.core because it won't be used until slapos.toolbox (actuall runner code) is changed to call them.

/cc @jerome @tomo @Nicolas

See merge request !751

This reverts commit de1e9ea0.

2.7.1+slapos006 revealed a bug in buildout bug, breaking resilient KVM.

Commit f355e0af didn't work because
GCC building ignores LDFLAGS when linking libgfortran.so
whereas the latter does not even need zlib and would be linked to
system zlib (if it exists) for nothing.

In our case, there seems to be no zlib code inside the installed files.

  This allow slaprunner call the API more easily.

  This may include basic usage of webrunner and as well basic
  resilience takeover.

The only change should be the upgrade of rdiff-backup
(from 1.0.5+SlapOSPatched001 to 1.3.4nxd6-SlapOSPatched001)
for some SR that extend the resilient stack.

For some SR, it implies the following upgrades:
- decorator: 4.3.0
- gitdb2: 2.0.5
- smmap2: 2.0.5
- subprocess32: 3.5.3

As https-only becomes default, tests are adapted in order to follow new
approach, case by case, or the redirect http->https is asserted, or https
access is used instead of http.

This is required for Python 3.7

- move or link instead of copying
- don't set too open permissions

See merge request !747

   This would allow the webrunner invoke it to bootstrap the instance
   rather them create the folders manually.

  Creating this file and updating the slapos.cfg configuration
  is possible to call slapos node format from the partition in the
  same way you would do in a computer.

kvm_controller_raw uses slapos.qemuqmpclient from slapos.toolbox

See the following error without this patch:

slapuser61@COMP-202:~/srv/runner/instance/slappart0$ /srv/slapgrid/slappart61/srv/runner/instance/slappart0/bin/kvm_controller_raw
Traceback (most recent call last):
  File "/srv/slapgrid/slappart61/srv/runner/software/1adf3dca589722a5eeac686fd4870ad0/bin/python-with-eggs", line 76, in <module>
    exec(compile(__file__f.read(), __file__, "exec"))
  File "/srv/slapgrid/slappart61/srv/runner/instance/slappart0/bin/kvm_controller_raw", line 9, in <module>
    from slapos.qemuqmpclient import QemuQMPWrapper, getInitialQemuResourceDict
ImportError: No module named qemuqmpclient

Modify components to make them compatible with `slapos.recipe.cmmi` shared mode.

Most of them were straightforward, except:

 - aspell, where all dictionnaries parts were installed in aspell part. Instead of this, we generate an aspell wrapper for each language. This wrapper runs aspell with environment variables so that it loads dictionnaries from the language.
 - fonts, where all fonts were installed in the same `${buildout:parts-directory}/fonts/` folder and where just installing a font part had the side effect to make this font available to every application. Now each font is installed separately and it becomes applications responsability to generate a fontconfig's fonts.conf and set `FONTCONFIG_FILE` environment variable to load it, as described in https://www.freedesktop.org/software/fontconfig/fontconfig-user.html . A new `template-fonts-conf` section was introduced for this.
 - mariadb, where mroonga plugin write in mariadb's folder. For this, mroonga plugin is installed in another directory along with all original mariadb's plugin (that are copied) and mariadb service is configured to use mroonga's plugin folder instead of the default mariadb's folder.

See merge request !706

Include a slapos command implemented with slapos standalone

See merge request !743

don't add automatic route when adding IP address on interface because
the automatic route doesn't add "via XXXXXX" gateway option.

In KVM setup, the host machine is the gateway. We need to go through the
gateway because we can't reach directly the other VM running on
different slaptap interfaces.

As SOFTWARE_HOME is added at the top of sys.path, this meant that Zope2.egg/Zope2
ended up at the top of sys.path:
  * This broke `imp.find_module('App')` and Pylint (`No name 'Extensions' in
    module 'App' (no-name-in-module)`) because there are `App` modules in both
    Zope2.egg/Zope2/ and Zope2.egg/ and the former was returned.
  * "Normal" instances and Products.ERP5Type.tests.runUnitTest properly set up
    SOFTWARE_HOME to Zope2.egg/.

Additionally, according to Zope2/Testing documentation, SOFTWARE_HOME is only
needed to find Zope2.egg/Testing module, already available as Zope2.egg is in
sys.path.

Mariadb was not shared, because installing mroonga writes a plugin in
mariadb's plugin dir and it's not allowed for one part to write in
another part's folder.

The approach is to install mroonga plugin in it's own plugin directory,
then copy all mariadb default plugins in this plugin directory and
configure instance to use mroonga's plugin directory.

Groonga also has plugins and we are using groonga-normalizer-mysql
plugin. Fortunately, groonga reads plugins located in paths listed in
GRN_PLUGINS_PATH environment variable, so we can use a simpler approach
of installing plugins in their own installation folder and set
GRN_PLUGINS_PATH in the environment of processes using groonga, ie. the
mariadb server process.

This test make sure that groonga-normalizer-mysql is functional