Introduce an easy way to run slapos commands in a more integrated way.

Instead of installing the software inside slaprunner from 1.0 branch, use the
same branch as the tested one, this should allow to see regressions earlier
(before they got merged in 1.0)

this profile was modified in c6cc45ab (all: apply eclint to unify empty lines
at end of file, 2020-08-05) but does not use buildout.hash.cfg, so md5sum was
not automatically updated.

Since f3613b91 (version up slapos.toolbox 0.110, 2020-08-21) slapos.toolbox needs lzma, which should always be installed with slapos component, because letting buildout install the egg from pypi would build against system libzma library (or fail if not present).
This introduce `*-dependencies` sections for eggs that have some dependencies that needs to be installed by slapos and use it, especially in section which install eggs from git for testing.

See merge request nexedi/slapos!804

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.

section to install dependencies of slapos.toolbox using slapos libraries

section to install dependencies of slapos.cookbook using slapos libraries

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