Sometimes during the first request to zope mariadb is not started yet and we
have an Site Error. In this case retry several times until we have a sucessful
response.

ERP5 software release has some support for mariadb slow queries:
 - run `pt-query-digest` daily
 - check that the number of slow queries and the slowest slow query do not exceed some thresholds defined as instance parameters

but this had issues:
 - the daily `pt-query-digest` reports where kept as not-compressed text files, which over time takes quite a lot of disk space
 - the threshold detection was not working, since strings and floats were compared - see slapos.toolbox!83

This uses new techniques in software release testing from slapos.core!245, we use [faketime] to simulate running crontabs and promises at a specific time in the future, so that we can assert the exact expected behaviour of crontab scripts.

[faketime]: https://github.com/wolfcw/libfaketime

See merge request !801

Since this version introduces a dependency on backports.lzma we had to
explicitly install backports.lzma in a slapos compliant way before installing
slapos.toolbox, because installing the egg needs xz-utils.

For slapos-sr-testing it's also a version up of backports.lzma to 0.14.0

Fixes problems with massive hosting and backend leaking to other definitions.

Starting from slapos.toolbox 0.110, this promise will report error if the the
amount of slow queries is over the threshold - before this version due to bug
in slapos.toolbox it was not - to keep this behavior and prevent too many
errors with this promise that is still in early stages of development, we
disable this promise unless it is explicitly requested in instance parameters.

These reports are large, no need to keep them as text

introduce test utilities to check crontabs using faketime and use it to check
that we produce full dumps of mariadb.

so that we can simulate running at a later time, to check backups, crontabs etc

This reverts commit 2c539421.

this prevented partially committing files (using git add -p), since it was
running git add on the full file in pre commit hook.

changes inside component where not checked because of this typo

The development of this component happened in environment which had a lot
of libraries available.

powerdns uses a socket named pdns.controlsocket in socket-dir (
https://doc.powerdns.com/authoritative/running.html#control-socket )
We sometimes see errors on test nodes that this path is too long:

     Aug 13 20:54:10 Unable to open controlsocket, path '/srv/slapgrid/slappart13/srv/testnode/cvr/inst/test0-0/tmp/inst/pdns1/var/run/pdns-socket/pdns.controlsocket' is not a valid UNIX socket path.

Instead of using "var/run/pdns-socket", put the socket in "var/run",
which should be short enough.

As cpu-count and ram-size can be setup freely by the user, the cpu-max-count
and ram-max-size shall follow it.

Otherwise it generates hard to track issues with starting VMs.

The image-url-list parameter is passed-thru only if it's present in the
original request, as the default instance differentiates correctly between
parameter existence or emptiness (or being None).

Downloadable images are enabled when key image-url-list (described in
instance-kvm-input-schema.json) is present.

Images are downloaded outside of partition processing, as this can take a lot
of time by template/image-download-controller.py

Configuration is checked and cleaned up by
template/image-download-config-creator.py

Promises are used for:

 * checking if the current configuration from the request has been processed
 * checking status of configuration generation, image download process and
   checksum validity

Details about errors are exposed by using monitor stack provided HTTP server,
so that user is able to take informed decision about how to fix the problem.

Wait even longer, as in some environments downloading big files takes a lot
of time which can lead to unstable test results.

Note: On fast environments the max won't be reached, so in such case the test
      speed won't be affected.

Interesting HTTP server from https://h2o.examp1e.net/

Some tests are checking deeply that bootstrap script works correctly inside
if prepared VM, but those prepared VMs are big chunks of data to be fetched,
so it's required to wait quite long.

   This contains data for running tests on Upgrade

This reverts 80af2841 and b4f83dd0.

We will force to compile gcc only in the machine preparing the source but not in the OBS machines actually compiling the packages.

The PYTHON variable is used in Makefile (https://gitlab.gnome.org/GNOME/glib/-/blob/2.58.3/glib/Makefile.am#L463) to generate the shebang for script gtester-report. With component/defaults.cfg, we have PYTHON=python2.7 so the shebang become '#!python2.7' which is an error for building a package on Fedora/SUSE:

[ 3269s] *** ERROR: ./opt/slapos/parts/glib/bin/gtester-report has shebang which doesn't start with '/' (python2.7)

The simplest solution is to remove this tester script as it is not needed and have been removed in newer version of glib already. This patch can thus be reverted when upgrading glib version.

Introduce an [editorconfig] configuration file to tell developer editors that we want an empty line at end of file.

After making softwares and component uses a buildout.hash.cfg file, run [eclint] fix to apply the style.

eclint is also added in the commit hooks (that one can install with `npm install` from the root of this repository)

[editorconfig]: https://editorconfig.org/
[eclint]: https://github.com/jedmao/eclint

See merge request nexedi/slapos!757