Allows to use recipe for cases when file is not present yet so it can return
some default (marker-like) value.

1.0.181 cannot be installed on Debian 11

This reverts commits d23929f7
(partially) and 3c52286b.

This issue is in slapos.core, slapos/testing/check_software.py:

      '*/parts/libreoffice-bin/*',
      '*/parts/java-re*/*',

We'll reapply the changes after (or at the same time as)
slapos.core is updated.

Make the md5 detection fix python3 compatible.

Fixes 4e5a9ee4

In addition to update version of slapos.recipe.build, this fixes the
following misuse:
- init phase must only initialize the section, which implies no change
  on the file system
- init/install/update's slapos.recipe.build should not contain buildout
  substitutions (theoritically, there could be wrong escaping,
  e.g. ${buildout:directory} containing quotes)
These 2 points didn't not matter here but it gave a bad example
for anyone learning buildout.

Thanks to the new buildout/slapos.recipe.build feature,
we can download the last released version of Debian Stable.

NEO stress testing is changed to run on both Debian 10 & 11.

Keep proposing Debian 10 netinst in kvm SR,
waiting that Debian 11 is more tested.

This fixes build of gevent on recent OS, due to missing greenlet
header file for Python 2.

- Clean up patch, mainly to not hardcode the fact that the recipe
  uses __compile__ suffix for build directory.
- Do not install *.o; install executables in bin/
- The URL didn't work anymore: switch to another one.

Each node requests a frontend instance used to publish information about
itself, but there was missing a promise on the node itself, if the frontend
instance is operational. Even if there is global cluster check of those
information, it does not trigger node reprocessing, thus adding additional
promise on each node.

For case if path (for zope) is provided from
/VirtualHostBase/https//example.com:443/zope_path/VirtualHostRoot/url_path
to
/VirtualHostBase/https/example.com:443/zope_path/VirtualHostRoot/url_path

If path (for zope) is not provided from

/VirtualHostBase/http//example.com:443//VirtualHostRoot/url_path
to
/VirtualHostBase/http/example.com:443/VirtualHostRoot/url_path

With Theia 1.17.2 we remain stuck on the loading page.

This reverts commit 6103d29a.

Instead of using complex mechanism with slaves (which are not monitored
anyway), allow the user to express monitoring with simple UI on normal
instance.

Additionally support for simple domains, not only URLs, is added.

See merge request !1048

If slaves clashes domain, this can lead to very bad situation, then only in
this case raise a promise error.

Otherwise the slave requester is informed anyway about the problem, so there
is no reason to make the whole cluster raising an monitoring issue.

Even if we don't use swig in our go projects, if hosting environment has
swig, but incorrectly installed, then Go build will fail as:

   --- FAIL: TestScript (0.03s)
       --- FAIL: TestScript/list_swigcxx (0.46s)
           script_test.go:252:
               # go list should not report SWIG-generated C++ files in CompiledGoFiles. (0.001s)
               # CompiledGoFiles should contain 4 files:
               #  a.go
               #  a.swigcxx.go
               #  _cgo_gotypes.go
               #  a.cgo1.go (0.421s)
               > go list -f '{{.CompiledGoFiles}}' -compiled=true example/swig
               [stdout]
               []
               [stderr]
               # example/swig
               :1: Error: Unable to find 'swig.swg'
               :3: Error: Unable to find 'go.swg'
               [exit status 2]
               FAIL: testdata/script/list_swigcxx.txt:12: unexpected command failure

Such broken environment, in particular, is present on our testnodes,
because there swig program is being included into slapos-node package,
slapos command includes it into $PATH for spawned programs

    https://lab.nexedi.com/nexedi/slapos/blob/99cf4bfd/component/slapos/buildout.cfg#L22-30
    https://lab.nexedi.com/nexedi/slapos/blob/99cf4bfd/component/slapos/buildout.cfg#L74-88

but the swig binary itself is configured to look into its supporting files in
the wrong place:

    slapuser91@vifibcloud-rapidspace-hosting-007:~/t/swig$ /opt/slapos/parts/swig/bin/swig -swiglib
    /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10

    slapuser91@vifibcloud-rapidspace-hosting-007:~/t/swig$ ll /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10
    ls: cannot access '/usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10': No such file or directory

which leads to SWIG being broken:

    slapuser91@vifibcloud-rapidspace-hosting-007:~/t/swig$ /opt/slapos/parts/swig/bin/swig -v -go -intgosize 64 a.swigcxx
    Language subdirectory: go
    Search paths:
       ./
       ./swig_lib/go/
       /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10/go/
       ./swig_lib/
       /usr/src/packages/BUILD/slapos/build/opt/slapos/parts/swig/share/swig/3.0.10/
    Preprocessing...
    :1: Error: Unable to find 'swig.swg'
    :3: Error: Unable to find 'go.swg'

-> Fix it by building SWIG ourselves and using that built swig to build go and
in the Go environment provided to users.

See "Troubleshooting" in http://www.swig.org/Release/README for details.

/cc @luke, @jerome, @romain