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.

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.

we always had the following warning:

INFO WARNING - several libperl.a found, taking only the first one: /srv/slapgrid/slappart71/srv/runner/shared/perl/aa50bea02bee72b0d400aaaa07ffd490/lib/5.28.1/x86_64-linux-thread-multi/CORE/libperl.a
INFO /srv/slapgrid/slappart71/srv/runner/shared/perl/aa50bea02bee72b0d400aaaa07ffd490/.build/perl-5.28.1/libperl.a
INFO Created symlink "libs-c" to lib/5.28.1/x86_64-linux-thread-multi/CORE

Depending on the order of the list, the link could point to broken
".build" path.

Fedora 36 and 37 were failing with following message:

cc -shared -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.12 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes
/usr/bin/ld: /tmp/ccrAYWgY.ltrans0.ltrans.o: warning: relocation against `zcfree' in read-only section `.text'
/usr/bin/ld: /tmp/ccrAYWgY.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `_length_code' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

OBS system is using user "abuild" to build the package rendering the
compilation broken.

Simply accept the 2 last commands to fail on Theia.