Backend logs are exposed as usual access and error logs.

By using rsyslogd templates and regex filtering, the rsyslogd reacts itself
and creates needed files per each slave which accesses it. Thanks to this, it's
configuration is static from point of view of SlapOS profiles, and can be
generated once.

As the rsyslogd configuration became fully special to backend-haproxy, the
rsyslogd template filename and its references has been correctly renamed.

Logs are critical for caddy-frontend, so let's configure rotate-num locally,
as changes in the stack can come unattended, and can result with loosing logs.

We moved out from local logrotate configuration long time ago, it was just
leftover.

haproxy by itself provides good information, so there is no need to add
information from rsyslogd itself.

The logrotate folder also serves as an publication folder for logs, so be sure
that logs are linked there.

While building haproxy on one machine, and using it on another, the CPU
optimisations can lead to haproxy not working at all on other CPUs.

In context of SlapOS packages are distributed in binary form, so haproxy
binary has to support all CPUs.

ATS was upgraded from 7.1.6 to 7.1.11

Patches taken from https://github.com/spack/spack/pull/15403

Setting max_version to 0 is less hacky. Also, it's not only for tarball
preparation, the package is created the same way.

There is no reason to drop connection to the backend and then reinitate it on
each request. It's better to keep connected and avoid additional work,
especially in SSL handshake.

Note: This was kept as the file has been copied from other place (haproxy
      on a backend), and slipped MR review, where MR author wanted to drop it
      anyway.

version up to current version (0.13.0) and include configuration to make use of nexedi/slapos.core!218

Also switch to gopls and include jdk, with all preliminary support for patchelf.

See merge request nexedi/slapos!774

we need the patch to be able to build with gcc 10 (used on Archlinux for example).
See https://bugs.gentoo.org/705898
patch is coming from https://705898.bugs.gentoo.org/attachment.cgi?id=603950

When running tasks, shell is invoked like:

   $THEIA_SHELL -c "command with arguments that\ can\ contain\ spaces"

The version from theia images does not support running from a plugin
installed in a read only folder, this newest version seem to work.

Also set the required java.home setting

So that gitlens extension (which can be installed per-workspace) knows
how to open files from lab.nexedi.com in browser

so that we can easily use python version 2 or 3 during development and
local testing.

This python is not directly usable with python extension, pip needs to
be installed as user, following:
https://pip.pypa.io/en/stable/installing/#installing-with-get-pip-py

by logging the process output

so that frontend requests are requested as theia computer partition.
Practically this means that if theia is installed on slapos master,
frontend requests for slapos inside theia partition will be requested as
this theia instance.

When updated to 4.8.1 the cursor "shadow" rendering is incorrect

workaround for https://github.com/eclipse-theia/theia/issues/8158

So that parts are shared when we install ERP5 in theia

Not much tested but it looks working

Even if we don't use this, the debug pane cause an error when jdk is not
installed

Some optional extensions installable from the registry (like the XML
supports from redhat) also need java and it's better to have something
to edit XML