Marking that publish failed is important, but allow the operator of the system
understand what is the real problem (aka - do not swallow exception
information) is also very important.

In nexedi/slapos@0cf70a6e we already migrated the NEO URI concatenation to the
recent format used by WCFS. Unfortunately we missed separating the address
(IPv6 + port) of the master nodes from each other. Without adding the
separator ',' between them, WCFS doesn't work with NEO clusters which have
multiple master nodes, because NEO/go can't split the different master node
addresses.

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 !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