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 nexedi/slapos!873

See merge request nexedi/slapos!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.

https://github.com/apache/trafficserver/issues/7417#issuecomment-757866872

See merge request nexedi/slapos!887

We want the tests to use the code from the repository, but when we have a
pinned version, buildout will use the code from repository only when the
version from the repository match the version spec from the pin.

The way slapos.recipe.template was pinned to 4.4 caused issues when we made
a change in slapos.recipe.template to make it 4.5, because tests were no
longer using code from slapos.recipe.template repository, but from 4.4 egg
from pypi.

To prevent this kind of issues, unset the slapos.recipe.template = 4.4
version pin and also unset the version for all tested egg, to prevent
similar issues if extended profiles also have version pins.

See merge request nexedi/slapos!876

This reverts commit 2f461da8.

Since Galene is behind our frontend, no need to take care of the HTTPS certificates.

See merge request !880

This also pulls in crawshaw.io/sqlite because it is used by lonet.

Due to unknown yet reason ATS and Caddy are loosing connections to haproxy,
which results with increased amount of 5xx (about 0.5% more cases).

No known solution was found yet on haproxy side, but this kind of workaround
stabilises frontend and definitely drops amount of in-frontend 5xx. The
observed situation with this workaround is no more 5xx sourcing in frontend
itself.