In e328aa49 (component/nxdtest: Prepare for nexedi/nxdtest!13)
I reworked how nxdtest script is generated and splitted it into nxdtest itself
and .nxdtest.pyexe python interpreter, so that sys.executable could be used to
correctly spawn other python scripts:

    3) rework how nxdtest script is generated and split it into .nxdtest.pyexe and
       nxdtest itself. .nxdtest.pyexe is python interpreter via which nxdtest is run.
       This interpreter has all eggs required by nxdtest in sys.path, so that
       nxdtest could spawn its trun.py via sys.executable. If we don't care to have
       properly setup sys.executable, trun.py will fail when importing any module that
       nxdtest.py could already successfully import.

       Initially I tried to workaround this issue via adjusting $PYTHONPATH <-
       sys.path in main nxdtest script, but @jerome points out that, $PYTHONPATH,
       if set, also affects processes that trun.py spawns, which is not good:

       nexedi/slapos!1095 (comment 146799)

       -> so fix this via running nxdtest via environment where sys.executable is
       properly setup python interpreter with path for all eggs that nxdtest has
       access to.

       Because we already have half-way workarounds for similar problem in several
       places, and because running a script with correctly setup sys.executable is
       generally better, I would say it should be a good idea to rework
       zc.recipe.egg:scripts to generate all scripts to work this way, but I do not
       want to fight about it.

       So let's leave this scheme nxdtest-specific for now.

This patch addresses the last paragraph and provides a general pyprog buildout
macro that could be used to generate python script for any entry point to run
with correctly set sys.executable.

/reviewed-by @jerome
/reviewed-on nexedi/slapos!1108

IMS and MME are in the same instance, but there is only one TUN
per instance. IMS is not crucial right now so we temporarily remove it
until we implement a clean solution.

We were trying to patchelf a file that apparently exists when Theia
is compiled on Debian 8, 10 and 11, but not on Debian 9.

See merge request !1105

Include the hash of all parameters related to the embedded instance
as a comment in the standalone script, so that if the hash changes,
the script and its own hash change as well, and standalone service
will be restarted.

Generate standalone script in instance-theia.cfg.jinja.in instead of
in software.cfg, avoiding the need to forward all the parameters.

Include the hash of the relevant parameters in the abstract socket path,
so that when changing these instance parameters the promise waits until
the standalone service has taken the new parameters into account.

Change "Embedded Instance" to "embedded_instance", and rename existing
"Embdded Instance" into "embedded_instance" for compatibility.

Installing will setup git hooks, so we can do one step further and
also configure the mergetool

otherwise curl uses system ca-certificates if the system package is
installed and otherwise is not able to verify server certificates,
usually being observed in slapos as git refusing to clone with error:
SSL certificate problem: unable to get local issuer certificate

See merge request !1103

On Debian 9, the given rpath seem to be ignored when compiling
the `keytar` dependency of theia, for unknown reasons.

- Move [theia] section and dependencies into component/theia
- Make [theia] section shared

This was missing in this software and in 03c5b311 (Stop using
hexagonit.recipe.download, 2021-12-03) the hash got out of sync

also mention automatic installation method

Since https://github.com/eclipse-theia/theia/pull/10343 theia depend on
nodejs >= 12 and they test on 12 and 14. Use 14 to have an officially
tested version.

This removes the strong requirement to have python2.7 in theia, so we
just use the software python, which might be python3

https://github.com/metabase/metabase/releases/tag/v0.41.4

We observed some test failures like for example 1 where this assertion
was failing because message is `Error reading SSH protocol banner`.

Because the purpose of this specific test is to check that log rotation
of ban log work as expected and because we test more thoroughly the
ban itself in TestBan.test_client_are_banned_after_5_wrong_passwords, we
can simplify this test by just asserting that connection was refused, by
expecting a general exception. We don't care about the details of the
exception here.

After a ban, the first connection attemps seem to always be refused with
"Connection reset by peer" and that's why we did not observed failures
with TestBan.test_client_are_banned_after_5_wrong_passwords

[1]: https://nexedijs.erp5.net/#/test_result_module/20211208-1520AC26C/21