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

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

See merge request !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

extracted from nexedi/slapos!735

there was a mistake in 2de4c80f, we
should sleep for the min duration of these two

This reverts commit 1bd4fc32

Frontend can now do SSL client authentication to the backend. This is turned
off by default, but easy to enable by proper switch.

In order to achieve this result haproxy has been introduced as middleman just
before the backend. Also it came with rsyslogd, as haproxy can't log by
itself.

Documentation has been updated, also changelog has been introduced.

A lot of additional tests has been added due to adding additional component
(haproxy) which required a bit different ways to approach to the request input
data.

See merge request nexedi/slapos!771

Despite the new system does not support promise failing scenarios, use a
simple way to have such configurations in late way and massively test various
important cases for rejection, error reporting and similar.

By default do not offer authentication certificate, the switch
authenticate-to-backend can be used on cluster or slave level to control
this feature.

rsyslogd is used, as haproxy does not support writing log files by its own.

This is needed in order to provide future support for client certificates
to the backend.

Also it means that haproxy is used in all cases, with or without cache, and as
a result the "cached" version of caddy is dropped.

Let haproxy setup maxconn by itself, as it's wise enough.

Also trust that it'll detect and use proper limits, instead enforcing them in
the shell with ulimit trick (ulimit -n $(ulimit -Hn)).

As empty server alias can impact the configuration, add proper test for
checking it.

It's required to fetch all dependencies in all cases, as tarball preparation
can happen on machine, on which gcc would be used from OS, but in the end
package building can happen on machines without proper gcc.

In some environments it is required to have gcc provided by SlapOS, and simply
forcing seems better than setting bugs min_version.

the name of constructed records should be unique so use the slave
reference instead of the "origin" parameter to be sure it is unique.

Before this change, if 2 slaves have the same origin parameter
"foo.com", we have the following in zone-files.yml:

    [...]
    sa.continent.foo.com:
      - cname: cname.of.slave1.for.sa
    [...]
    sa.continent.foo.com:
      - cname: cname.of.slave2.for.sa

So only the cname for slave2 will be used.

extracted from nexedi/slapos!735
and updated to 0.11

Instead of passing various kedifa information to the profile generating
configuration use section kedifa-configuration and access later such grouped
values.

In context of frontend node reuse passed directory section to slave
configuration to improve readability and simplify future enhancements.

This reverts commit 92fd6909, which
incorrectly added test assertion files with 'test.test'.