`autorun` controls the `slapos-node-auto` service:
  - `running`: start `slapos-node-auto`
  - `stopped`: stop `slapos-node-auto`
  - ( else ) : leave `slapos-node-auto` as it is

Adding monitor stack allows to use the monitor, then passing the profile and
extending it allows to correctly deploy.

Since haproxy checks the test server for availability and does it
asynchronously, the test server has to reply ASAP for given request, but when
one request blocks, then whole server is blocked, so just simply switch it to
threading model.

It's not the best, but good enough for test usage.

backend-active-check is really long and technical name, whereas health-check
is well known description of backend checks.

X-Reply-Status-Code follow usual way to configure responses.

This verification happens on the connection to the backend with
backend-haproxy component, and changes like type of the slave or cache usage
does not impact it.

Several softwares were using fixed versions, but versions are also defined in
stack/slapos.cfg, so let's use from stack/slapos.cfg which will simplify
version management.

This urllib3 has visible changes for us, it no longer send the request path
"as is", but normalizes the . and .. which is not what we want in
caddy-frontend test, so we adjust the test to use prepared requests, which is
the recommended approach for this kind of low level needs. Since prepared
requests does not set default user agent "python-requests", tests checking that
user agent is in log files have been adjusted to use a dedicated test user agent
header.

Another change is that certificates are now verified by default, so we adjust
seleniumserver tests to disable certificate validation. jstestnode, already
had a patch regarding certificate validation, because we wanted certificates
to be validated before it was the default. We just update this patch a bit
because we want to keep the optional behaviours of validating against a
specific CA or to disable validation.

also update slapos.toolbox to 0.116

Default and cluster are tested for the most expected usage.

This test uses the default config of having mariadb log queries taking more
than 1 second, then makes two slow queries and check that these two queries
are logged and included in pt-query-digest report.

Sometimes this test fail because there are more slow queries than the two
expected, in the snapshots, we can see that reports also contain:

    SHOW TABLE STATUS FROM `mysql` LIKE 'time_zone_transition'\G
    SHOW CREATE TABLE `mysql`.`time_zone_transition`\G

but these queries are not made by the test. They are probably made by
mysql_upgrade script. Such queries can take more than 1 second sometimes
and when they do the test fail because there are more slow queries than the
expected.

To prevent this kind of intermitent failures, make our test queries slower
and configure mariadb to log queries after a longer delay (3 seconds).
Hopefully these unrelated queries should not take more than 3 seconds.

217f7f05 (slapos-testing: don't pin tested eggs, 2021-01-12) was wrong,
some versions needs to be pinned for initial installation of the software.
The problem was not visible when the software was already installed and
updated in place, but when installing software from scratch, it was failing
very early with an error like:

    While:
      Bootstrapping.
      Getting distribution for 'slapos.libnetworkcache'.
    Error: Picked: slapos.libnetworkcache = 0.20

By using a late instance creation, it's possible to escape requirement of
the cluster being fully instantiated by default, so it's possible to test
various interesting corner cases.

Fixes:
  * fail fast in case of trouble
  * treat 1.0 as special working branch and be ok to remove it
  * select origin/1.0 as source of the local 1.0 branch

Thank to this it can be used in clean repository.

Fixes:
 * fail fast in case of trouble
 * treat 1.0 as special working branch and be ok to remove it
 * select origin/1.0 as source of the local 1.0 branch

Thank to this it can be used in clean repository.

Thanks to shacache it will be cached anyway, and it allows to easily refer
to the source changes and eventual discussion.

Since Jinja 2.11 it's possible to do nice tests against true, false and
others, which is important for various type checks.

Since "caddy-frontend: Switch monitor ports to internal use" monitor ports
are internal usage only and this test is obsolete.

It's not used at all in current approach.

The public-ipv4 comes from the historical usage of the system, but since
new implementation came into place it was never needed, so now it's time to
say goodbye.

Test has been updated to do in-house mimic of the used IP to access.

It's from old approach, which is not going to be implemented.

Since recent change the virtualhostroot-https-port and
virtualhostroot-http-port are casted to integer during configuration
generation so it's require to validate this input and reject incorrect values.

As decision making quite often requires access to more than one slave entry,
it's better to keep the logic above configuration generation. Also
configuration generation is already complex, and it's better to have it
simplified, especially in case of switching the component.

Use already prepared values from apache-custom-slave-list.cfg.in in
default-virtualhost.conf.in to simplify even more.

Pass variables to the other profiles without casting them to string, so that
they work out of the box.