The access log is useful for usual analysis, but CDN has to provide deep
metrics regarding each request, thus implement the frontend log, which follows
more or less HAProxy's httplog
http://docs.haproxy.org/2.6/configuration.html#option%20httplog and can be
correlated with a timestamp to access log.

The URI string is dropped from the frontend log, as it's already supported by
the access log. Thanks to this it's safe to use !!! (triple exclamation mark)
to split the log line, as those characters are not expected to be found in
usual metrics provided by HAProxy.

See merge request nexedi/slapos!1383

Expose and document HTTP3 related cluster switches.

Switch to Recurls with HTTP3 enabled curl for testing.

%HU in case of HTTP/2 results with full URL being logged, while just the path
is expected in the log.

Even if the change comes from http://git.haproxy.org/?p=haproxy.git;a=commit;h=30ee1efe676e8264af16bab833c621d60a72a4d7
it has been detected since full HTTP/2 aware test client has been used.

This class mimics requests, but as an engine to access sites it uses curl
command, which is expected to be provided with a lot of features, including
full HTTP3 support.

It's fetched from the upstream repository with well known working revision.

It's very important to have readable and contextable information on failures,
in order to track root cause of the problem.

The portredir slapos.core manager won't be used in CDN deployments.

It's very usefuly to have access to such powerful tool on each CDN node, and
we shall eat our dog food anyway.

This is the only way to be assured that all expected headers are going to be
sent back to the client.

Embrace frontend name in {} and then use such "schema" to catch it during
logging. This lowers the risk of incorrect log file generation or misplaced
log lines.

In commit 547898ee
"component/openssl: Use the newest openssl with QUICTLS" there untested
upgrade to openssl-3, which has side effects with loading expired certificate
chains.

use dropdb and createdb command is a working approach to backup
restoration here

This reverts commit 8218f34a.

This did not work at all

* Rename mme software type to core-network since mme is a 4G terminology
* Rename template-lte-XXX to template-XXX since lte is a 4G terminology

* Remove gnb-epc and enb-epc software types and merge mme and epc together

In practice, the restoration was always failing with errors like:

  pg_restore: [archiver (db)] could not execute query: ERROR: schema "???" already exists

because the database was first initialized, but the usual restore
scenario is:
 - instance is populated with initial data
 - data is replaced by restoring the data

this also change the timeout to 5 seconds, 30 is too much

This was for ZServer

This makes yaml module to zope processes. The package was already
installed because it is an indirect dependency, but not in the working
set of zope processes

See merge request nexedi/slapos!1378

This only support python3 since some time

slapos.toolbox no longer supports python2, this pins to the last version
where the test passed on python2.

In nexedi/slapos.toolbox!116 (comment 181641)
we agreed that if we need to fix a python2 bug or backport something
critical, we can make a version 0.128.1 (based on 0.128 with the fix
for python2)

The recipe slapos.cookbook:requestoptional may cannot finish the request
correctly during slapos node instance. With slapos.cookbook:request,
the waitForInstance can retry multiple times until the request finished.