GitLab

This is a big changes for users, now typing "python" on the command line
will use system python if it exists or fail with "command not found".

`python3` is set to the SlapOS python from Theia software release.
Recommended approach for python users is either to get used to type
`python3` or to create a virtualenv and use it. With the virtualenv,
they can also install pylint or other linters, so this might be the
best thing to do.

This solves two problems:

First problem is that it makes the embedded SlapOS always have a python
interpreter as `python` in $PATH, which is not always the case in other
SlapOS usage and can hide problems that would cause a software to build
successfully in Theia but not in "bare metal" SlapOS.

Second problem problem is that on python was a interpreter from pygolang
and it is not perfect regarding line edition at least on python 3.8, as
we can observe in this session:

run python and type "something":

```
Python 3.8.13 (default, Sep  6 2022, 10:45:07)
[GCC 8.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> something
             ^ cursor is here, as expected
```

type Ctrl+A to go to beginning of line:

```
Python 3.8.13 (default, Sep  6 2022, 10:45:07)
[GCC 8.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> something
    ^ expected cursor position
^ actual cursor position
```

likewise, type Ctrl+E to go to end of line:

```
Python 3.8.13 (default, Sep  6 2022, 10:45:07)
[GCC 8.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> something
             ^ expected cursor position
         ^ actual cursor position
```

Change python2 softwares to use python2 explicitly and python3
softwares to use the default, but leave a few softwares (html5as,
html5as-base, fluent-bit, packer, seleniumrunner) using the default
python, as they were using python2 not because they only support python2
but because they don't have strong dependency to the python version
being used.

Remove existing "embedded instance" options:
- `embedded-sr`
- `embedded-sr-type`
- `embedded-instance-parameters`

Instead introduce `one-time-embedded-instance` option:
- Only taken into account when Theia is instantiated the first time.
- Content should be a JSON object with:
  - 'software-url': string of the software URL
  - 'software-type': (optional) string of the software type
  - 'instance-parameters': (optional) JSON object

If the option is non-empty:
- Theia will attempt once to:
  - Parse the JSON content
  - Create a supply/request script
  - Call the script
- A promise will check whether the script was successfully called.

If the promise fails forever, e.g. because of ill-formed JSON, emptying
the option will remove the promise. Editing the option after the first
time will have no effect, whether the promise succeded or not.

theia, erp5testnode are both running a slapos standalone. We don't
change slaprunner to python3 because it's not maintained anymore and
should disappear in the near future.

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.

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

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

It appears no longer needed to use LD_LIBRARY_PATH to ensure the
correct runtime path resolution of libsecret in theia's `keytar`
component. Also LD_LIBRARY_PATH was leaking into theia's environment
and affecting tests launched from within theia.

This reverts commit 681ec188.

Always format the partitions to ensure the slapformat configuration is
valid, because the constructor overwrites it with invalid values.

We need a valid configuration so that `slapos node format` works,
and we need `slapos node format` for the resiliency import script.

To have the timeline view

Eventhough our current pattern is not the most secure, we have no other
choice for now that to use such insecure patterns.

In https://erp5js.nexedi.net/#/bug_module/20210819-20614EE we track possible
improvements to this situation.

This new version has a dependency to libsecret

Also adjust dependencies to the ones from https://github.com/eclipse-theia/theia/blob/v1.16.0/examples/browser/package.json
except api-samples which is not useful.

Before this commit, instance parameters that have a default null value
in JSON format were rendered as 'None' string in instance-theia.cfg.

In particular, Theia frontends were always requested with unsolvable
SLA parameters that prevented a frontend from ever being allocated:
```
sla-instance_guid = None
```

This option takes a string representing a valid JSON object and
forwards the corresponding python dict to the embedded instance.

This defers the rendering of `instance-theia.cfg.in` to the instance
creation time instead of the software installation time, which will
allow buildout sections to be added based on the instance parameters.

See merge request !981

Eventhough "others" can not enter the parent directory, there was no reason
to have such open permissions

The client side was reimplemented in node, to workaround segmentation faults
with python/ncurses.

Before this commit, running
  'slapos node software'
and
  'supervisorctl start slapos-node-software'
behaved differently because the PATH and other environment variables
where different in the interactive theia shell and in supervisord.

See merge request nexedi/slapos!935

Instead of having softwares install yarn, unify this in nodejs stack.

Yarn usage is similar to nodejs usage, if a specific version is needed,
software should use macro to expose which yarn version to use, example:

    [yarn]
    <= yarn-1.17.3

Then sections can use yarn by having ${yarn:location}/bin/ in their path.

yarn will use the default [nodejs], so to another nodejs version, the same
pattern can be used:

    [nodejs]
    <= nodejs-10.6.0

See merge request !913