Fixes building gcc-8.5.0 on libc6 version 2.36 (at least).
Fixes this error:
  configure: error: in `.../parts/gcc-8.5/.build/gcc-8.5.0':
  configure: error: C compiler cannot create executables
  See `config.log' for more details.
relevant config.log extract:
  configure:4326: gcc   -Wl,-rpath=.../parts/gmp/lib -Wl,-rpath=.../parts/isl/lib -Wl,-rpath=.../parts/mpc/lib -Wl,-rpath=.../parts/mpfr/lib conftest.c  >&5
  .../parts/binutils/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: unknown type [0x13] section `.relr.dyn'

because this metabase now needs SNI properly configured, which means
that the backend must know the frontend domain name and can not be
accessed by its IP address, we stop serving https on IPv6 directly from
metabase's embedded jetty and reconfigure it to serve http on IPv4 and
add an haproxy instance to serve https on IPv6. This is just an
"internal" change because the external IP will be same and the
certificate is still a self-signed one for now.

references:
 - https://github.com/metabase/metabase/issues/29660
 - https://discourse.metabase.com/t/http-error-400-invalid-sni-when-upgrading-from-0-45-3-to-0-46-0/24599/8

The configuration of caucase used here is to have certificates valid for
3*31 days and renew them 31 days before the expiration date.
This test was running the updater 2 months later, which by chance was
62 days at the time of the test was written, because this test was
written in July (both July and August have 31 days), but this does not
work in other months.
Adjust the test to run the updater using a fixed number of days in the
future.

note: updating to a more recent version would require more changes
because now jetty must have a certificate matching the hostname, see
https://github.com/metabase/metabase/issues/29660#issuecomment-1496625318

Since go1.18 is no longer supported, we should switch to a newer
version (("Each major Go release is supported until there are two
newer major releases" [1]).

[1] https://go.dev/doc/devel/release

/reviewed-by @kirr
/reviewed-on !1417

We should upgrade to Go 1.20, because Go 1.18 is already no longer supported.
("Each major Go release is supported until there are two newer major releases" [1]).
Go 1.20 is the incremental improvement for earlier go 1.19 release.
We skip Go 1.19, because it's also unsupported as soon as Go 1.21 is
released (this is expected to happen in one month [2]).

Please find all details in the official release note:

    https://go.dev/doc/go1.20

It was released on 2023-02-01 [1]. Due to the go promise of compatibility
most software should still compile without any problems.

We need to differentiate between go before 1.19 and go after 1.19, because
go before 1.19 needs TestSCMCredentials patch, while starting from go
1.19 this patch has been applied upstream [3].

[1] https://go.dev/doc/devel/release
[2] https://tip.golang.org/doc/go1.21
[3] https://github.com/golang/go/commit/f839aaa22b66bc556fac72f7396082212d2ef45d

/reviewed-by @kirr
/reviewed-on !1417

See merge request !1415

Forward enb.xlog to another fluentd or fluentbit server using fluentd's
forward protocol.

Currently, TLS is enabled and a pre-shared secret key is used for
authentication, but certificate verification is disabled.

Since the wendelin.core 2.alpha3 release 9 month ago, new fixes
were added to wendelin.core, which we would like to have in SlapOS.
One very important new feature is that this wendelin.core version now
support golang 1.20, so with this we can easily proceed to upgrade our
default golang version.

/reviewed-by @kirr
/reviewed-on nexedi/slapos!1416

without this cleanup, the software integration tests of KVM were stuck
forever because unittest was waiting for the subprocess to stop.

if '-ltinfo', '-ltermcap' or '-lcurses' is set in the linker option,
sqlite3 binary wil link to system libtinfo like this:

slapsoft@tomo-node:~/shared/sqlite3/39068f3749274fa37ab3897081678816/.build/sqlite-autoconf-3370200$ ldd sqlite3
	linux-vdso.so.1 (0x00007fff6dfe6000)
	libreadline.so.8 => /opt/slapgrid/shared/readline/13387ca15e2015da77fab391a268aaa6/lib/libreadline.so.8 (0x00007f4418d7d000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f4418d40000)
	libz.so.1 => /opt/slapgrid/shared/zlib/ac3692dceab375c8e6b9c06735e5faf2/lib/libz.so.1 (0x00007f4418d1b000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4418bd7000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4418bd1000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4418bad000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f44189d9000)
	libncurses.so.6 => /opt/slapgrid/shared/ncurses/13a31fd4ae4eaba4a72e42f42c997f1c/lib/libncurses.so.6 (0x00007f441897c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4418f5a000)

if libuuid was present on the system, python would link with it in:
lib/python3.9/lib-dynload/_uuid.cpython-39-x86_64-linux-gnu.so

if libtinfo was present on the system, readline would prefer to use it instead of libncurses

This will let a non-shared Theia (for example coming from shacache
binary) to be able to use the shared parts of a machine.

See merge request nexedi/slapos!1409

See merge request !1407

See merge request !1399

Fix takoever of a theia with initial embedded instance. The issue was
that the promise checking that the embedded instance was successfully
requested relied on files which were not transferred to backup theia.

The location of these files has been changed in order to transfer them;
therefore the old location is still checked for upgrade-compatibility.

Test that takeover of theia with an initial embedded instance succeeds.