see nexedi/gitlab-workhorse!4

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.

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

Users will need to generate a proper fonts.conf and set it as
$FONTCONFIG_FILE environment variable.

The recommended approach is now to generate a font.conf file using
slapos.recipe.template:jinja2 since font.conf now needs entries for all
directories containing fonts.

Instead of the previous approach which relied on a side effect of
installing *-fonts parts that would write in parts/fonts/ and make the
fonts automatically available to applications, use a new approach where
each part is "pure", without side effects.
To make the fonts available to applications, a fontconfig font.conf
listing all the parts with fonts needs to be generated and set as
$FONTCONFIG environment variable.

A template font.conf is included in component/fontconfig

We now need to refer to the part where the dictionnary was installed.