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.

Following up nexedi/slapos!858 to
support milliseconds timings in access logs

Remove unused "plugin" entry.
Add locally-referenced-but-defined-by-another-file "bin".

Should have been part of:
  commit c787d04c
  Author: Hardik Juneja <hardik.juneja@nexedi.com>
  Date:   Thu Jun 8 18:39:28 2017 +0200

      remove unnecessary monitor_template section form erp5 stack

Since bd3c2b18 (Remove httpd from ERP5 and use haproxy instead, 2020-12-14)
timing in balancer access log files are in milliseconds, no longer in
microseconds as they use to be with apache.

We update apachedex to version 1.8, where it supports generating reports
from access log files with milliseconds, as long as the expected format is
passed with --logformat argument.

We changed the default value of apachedex configuration to use the expected
--logformat argument, but users with a custom apachedex config passed as
instance parameters (monitor.apachedex-configuration) will have to update
their request parameters, to also pass --logformat.
Since this is breaking change, we take this opportunity to introduce another
breaking change, this parameter is not longer a string with all arguments
on the same line, which was problematic because these arguments contained
quotes and backslashes. The arguments are now passed as a list of strings
which will become the list of arguments passed to apachedex.

This is implemented by generating an apachedex config file, which simplifies
the generation of the wrapper. For this we also needed to upate
slapos.toolbox.

The same change is reflected to the overriden profiles in slapos-master,
but for slapos-master we don't pass the --logformat argument, because
slapos-master is using httpd, so the logs timings are still in microseconds.

90 bugs fixed since 2.0.17:

 * 6 major
 * 30 medium
 * 54 minor

See http://www.haproxy.org/bugs/bugs-2.0.17.html

Thanks to work on TrafficServer bug 7425 it was possible to understand
correctly the switches and setup ATS to SlapOS CDN needs.

max_stale_age with negative_revalidating_enabled is used to simulate
stale-if-error and negative_revalidating_lifetime is set to 0, as Expires
header provided by this switch is needless in SlapOS case.

Tests are updated to follow the real use case, by rewriting ATS configuration
to meet times required for the test to finish in reasonable time.

Update to 1.9.0 ( https://github.com/eclipse-theia/theia/blob/v1.9.0/CHANGELOG.md#v190---16122020 )

Update extensions to newer version and to the URLs from openvsx instead of
github, since openvsx prevent maintainers to modify releases.

Also use buildout directly to download extensions, so that we verify signatures and have possibility to use cache

See merge request !873

See merge request !886

In reality, proxy.config.http.cache.max_stale_age was used for stale cache lifetime in current ATS implementation.
Thus we increase proxy.config.http.negative_revalidating_lifetime value to the same value as proxy.config.http.cache.max_stale_age whose default is 604800.