slapos-testing, slapos-sr-testing: Don't duplicate instance.cfg prologue that is already provided by stack/nxdtest/instance.cfg

This software releases switched to nxdtest in 1536ad2e (software/slapos-testing: use nxdtest)
and 3a1e5628 (software/slapos-sr-testing: use nxdtest). So there is no
longer need to duplicate that standard instance prologue that is
provided by stack/nxdtest/instance.cfg:

https://lab.nexedi.com/nexedi/slapos/blob/0803b816/stack/nxdtest/instance.cfg.in#L1-8

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

On older kernels (like default one in Debian 9) firewalld is failing with:

'python-nftables' failed: internal:0:0-0: Error: Could not process rule: No such file or directory

when nftables backend is used.

As firewald component shall be compatibility layer, it shall work on most
different operating system, and for today it seems the way to make it really
compatible.

Missing exec results with receiving signals to the wrapper itself, leaving
the child process escaping signal control.

See previous commit.

This may lead to weird like ...//... or worse: here, the [gcc] part of
the tested SR will do "os.path.dirname('/usr/bin/')" (when using system
gcc), causing ${gcc:prefix} to be invalid ('/usr/bin' instead of '/usr')
and most sharable parts will rebuild (different [gcc] signature).

See c170fe3e and nexedi/ZODB@8e7eab33
where ZODB4-wc2 is introduced.

See c170fe3e and ZODB@8e7eab33
where ZODB4-wc2 is introduced.

See merge request nexedi/slapos!867

add frontendhtml5as: add frontend

To always call loadBefore instead of load.
Wendelin.core 2 needs this - see ZODB@8e7eab33 for details.

There is also ZEO4-wc2 which contains backports of ZEO5 patches that are
needed for wendelin.core 2 to work correctly.

Wendelin.core 2 will work with ZODB4-wc2 or ZODB5.
Wendelin.core 2 will not work with just ZODB4.

Factor-out things that provide components for ZODB stack from software/neoppod/
into component/ZODB/.

See merge request nexedi/slapos!935

See merge request nexedi/slapos!929

For now it's used only in repman, but instead of compiling from source it was
using a pre-build binary for linux64. This change to compile from source.

See merge request !933

The version >=5 is not python2 compatible.

instead of downloading a pre-binary that might not match the architecture

We still need to checkout from git these packages, because most
of them use `replace` in their go.mod, which is only compatible
with installing as main module, but not as an external module.

promtail will use go-systemd when cgo is enabled, but we don't
want to ship a full systemd in slapos, so we build with CGO_ENABLED=0

grafana on the other hand needs to be build with CGO_ENABLED, because
it will use sqlite3. grafana also needs to use yarn to build the
frontend, so it remain a dedicated section with ad-hoc installation
method.

Run this whole script in `set -e` so that if any of the go install
fail buildout exit with error.

With this new environment option to gowork section, it is possible
to specify environment variables that will be set during the build,
more specifically when env.sh is sourced.

The implementation is a bit complex, so that the syntax is not strict
and whitespace are tolerated in the definition, ie. all these should be
understood:

    [gowork]
    environment =
      A=a
      B =b
      C= c
      D=d=d

json-schemas test is complaining that some jsons are not formatted according to
this standard.

to make management of this template easier

       Partially updated from original instance-erp5.cfg.in file.

Xavier Thompson reports that when Theia is compiled inside Theia, Go
fails to install with the error showing that golang14's make.bash calls
`go install` to install cmd/go and other commands to the outer
go.work/bin instead of inside $GOROOT_FINAL set by the build recipe.

Similarly to nexedi/slapos!928 this
might be to the fact that internal `go install` prioritizes $GOBIN even
in the presence of set $GOROOT_FINAL.

-> Don't try to fix Go itself, and make the compilation more robust by
unsetting $GOBIN, so that even if that variable is set in the
environment where buildout runs, it does not affect the compilation
procedure.

Fixes: 8eac67a5 (golang: Prepare for future GOPATH removal)
Reported-on: https://www.erp5.com/group_section/forum/Go-compilation-error-P6f5WisQkc
Tested-by: @xavier_thompson
Reviewed-on: nexedi/slapos!932

   Partially updated from original instance-erp5.cfg.in file.