This complements 7f877621 (Move wendelin.core from Wendelin to ERP5) and
introduces new WCFS service into ERP5 software-release to support
upcoming wendelin.core 2. Wendelin.core 2 will introduce new WCFS
filesystem server component that serves in-ZODB arrays data as OS files
for Zopes to memory-map. Please see the following links for overview of
what WCFS is and how it interoperates with and serves Python clients:

https://lab.nexedi.com/kirr/wendelin.core/blob/b5fc98bb/wcfs/wcfs.go#L20-247
https://lab.nexedi.com/kirr/wendelin.core/blob/b5fc98bb/wcfs/client/wcfs.h#L20-96

Implementation notes:

- WCFS is by default disabled in ERP5 - we do not want to load every
  ERP5 user with it in the early days of wendelin.core 2. WCFS service
  will also not work when ERP5 is built with wendelin.core 1, so keeping
  it disabled by default is reasonable for now.

- There is a duplication for instance-erp5.cfg.in in between stack/erp5/
  and software/slapos-master/ . It was negotiated with VIFIB developers
  to go this way instead of first deduplicating instance-erp5.cfg.in
  copying that was started in 87d13789 (slapos-master: Copy files from
  erp5 stack for local changes).

To enable wcfs one can either pass `wcfs` configuration parameter, or
add the following to a software-release that uses stack/erp5:

  [erp5-defaults]
  wcfs-enable-default = true

/cc @rafael, @tomo

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 nexedi/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 nexedi/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 nexedi/slapos!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.

Introduces devperm manager with lsblk.

Use json to generate .slapos-disk-permission in a way, that devperm manager
will be able to consume it.

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

Use-case: when an host enry is used to define the outgoing binding IP of
zopes in a partition, this IP is host-dependent.

So that it proagates root instance's "balancer" parameter, as other
request-* sections do. No functional change is expected, this is rather
for code simplification and factorisation.

use this new mechanism, which avoids this parameter being misused
(inconsistent between partitions of the same family).
Preserve backward compatibility, giving precedence to the new mechanism.

Call them deadlines, as this is what they really are, but the "wrong" name
stuck on ERP5 side (for now).
Also, introduce a per-family-override mechanism, to avoid having per-
option equivalents for such mechanism.

Also, stop poping it: nothing else seems to be accessing the containing
dict, so mutating it does not seem necessary.

gitaly's Makefile forcibly sets $GOPATH to install in _build
folder. Once gitaly is built, it is expected to be in _build/bin/gitaly
and copied from there.

With 8eac67a5 (golang: Prepare for future GOPATH removal, 2021-02-26) the
env.sh sets GOBIN, to its own $GOPATH/bin

Since gitaly's build does not set $GOBIN, even if it overrides $GOPATH, the
final bin/gitaly is not in $GOPATH/bin/gitaly (with $GOPATH from Makefile),
but in $GOBIN/gitaly (with $GOBIN from env.sh)

To prevent this, unset $GOBIN before running make, which keeps the old
behavior of only using the $GOPATH from the Makefile