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

Go1.17 is incremental improvement over Go1.16 with better and faster compiler,
runtime, module-mode improvements and faster generated code:

https://blog.golang.org/go1.17
https://golang.org/doc/go1.17

Drop support for Go1.15, as that release reached EOL and nothing currently uses
it in SlapOS.

Don't drop support for Go1.12 yet, as that long-ago-EOL and no longer supported
Go release is still being used by software/gitlab.

Remain default at Go1.16 yet.

Switch helloworld to Go1.17 and test this patch on that
software-release.

Going Go1.16.4 -> Go1.16.8 brings in fixes to compiler, runtime and stdlib
including security fixes to net, crypto/tls, archive/zip, math/big, and
net/http/httputil packages:

https://golang.org/doc/devel/release.html#go1.16.minor

Tested on helloworld SR.

2021/09/07 : 2.0.25
    - BUG/MEDIUM: sock: really fix detection of early connection failures in for 2.3-
    - REGTESTS: abortonclose: after retries, 503 is expected, not close
    - BUG/MEDIUM: base64: check output boundaries within base64{dec,urldec}
    - MINOR: compiler: implement an ONLY_ONCE() macro
    - BUG/MINOR: lua: use strlcpy2() not strncpy() to copy sample keywords
    - BUG/MINOR: ebtree: remove dependency on incorrect macro for bits per long
    - BUG/MINOR threads: Use get_(local|gm)time instead of (local|gm)time
    - BUG/MINOR: tools: Fix loop condition in dump_text()
    - CLEANUP: Add missing include guard to signal.h
    - DOC: configuration: remove wrong tcp-request examples in tcp-response
    - BUG/MINOR: config: reject configs using HTTP with bufsize >= 256 MB
    - CLEANUP: htx: remove comments about "must be < 256 MB"
    - BUG/MAJOR: htx: fix missing header name length check in htx_add_header/trailer
    - Revert "BUG/MINOR: stream-int: Don't block reads in si_update_rx() if chn may receive"
    - MINOR: action: Use a generic function to check validity of an action rule list
    - REGTESTS: mark http_abortonclose as broken

This reverts commit a42d199a.

Add Software Release to provide scripts to run Time-Sensitive Networking
motor demo.

The python snippet has to print calculated value.

This fixes commit 7d7a59d6
stack/cacuase: Make rerequest updatable

See merge request nexedi/slapos!994

See merge request nexedi/slapos!1013

- rubygemsrecipe deployment mode now depends on `allow-picked-versions` by default

sotware/caddy-frontend: Use instance-caddy-replicate.cfg to replace buildout-switch-softwaretype.cfg

Because when using the switch-software, the
buildout-switch-sofwtwaretype.cfg will not be generated, see
https://lab.nexedi.com/nexedi/slapos/blob/master/slapos/recipe/softwaretype.py#L264-267
So use instance-caddy-replicate.cfg instead, which has same effect.

Changes explanation:
slave_reference.lower(): The configparser which the current buildout
using is case sensitive, which cause some options cannot be found.
slap_software_type: The recipe softwaretype need this option, but
switch-softwaretype doesn't.
caddyprofiledeps: It provides the deps of caddy. Switch to
switch-softwaretype leads to the error like "ImportError: No module
named furl". Force caddyprofiledeps installed first can solve this
issue.

See theia's [changelog](https://github.com/eclipse-theia/theia/blob/v1.16.0/CHANGELOG.md#v1160---7292021), we update from 1.13.0 to 1.16.0.

Changes specific to slapos port:
 * We set `warnOnPotentiallyInsecureHostPattern` because the new warning is very intrusive ... but it might actually be very insecure. For now we don't have solution. We are tracking this in https://erp5js.nexedi.net/#/bug_module/20210819-20614EE
 * New libsecret component that is now required by theia
 * Switch to using vscode git instead of theia git, to use timeline ( see https://github.com/eclipse-theia/theia/pull/7997 )
 * globally version up slapos.core to https://pypi.org/project/slapos.core/1.6.18/

See merge request !1039

To have the timeline view

This is basically the same problem as in 1b291415
(component/ghostscript: Workaround for slaprunner paths with double
slashs, 2021-06-02)

The issue is now fixed in 1.16.0

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.

See merge request nexedi/slapos!1027

See merge request nexedi/slapos!931

The resiliency pull-backup-server status feed file `pbs-status-rss`
is generated by a cron running every 5 minutes. But there is a promise
that requires it to check the notifier status, meaning instanciation
fails until this file is available.

To allow the promise to succeed immediately, we generate the
feed a first time directly from buildout.

The resiliency notifier status feed file `notifier-status-rss`
is generated by a cron running every 5 minutes. But there is a
promise that requires it to check the notifier status, meaning
instanciation fails until this file is available.

To allow the promise to succeed immediately, we generate the
feed a first time directly from buildout.