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

Update grafana, to use more recent golang. This also brings support of multi line logs in loki.

See merge request nexedi/slapos!921

See merge request nexedi/slapos!925

When the outside world path does not match the Zope path (typically: Web
Site).

By adding failover url the user is able to configure special backend to use
in case if the real backend is down.

Original PoC was done by Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>.

Both loki and promtail were not configured properly and listening on all IPs.
This was partially because doc was wrong at the time, but also this was not
done properly.

update softwares to:
  - grafana 7.4.3
  - telegrah 1.17.3
  - influxdb 1.8.4
  - loki current master ( 2.1.0 )

and components to:
  - golang 1.16
  - nodejs 14.16.0
  - yarn 1.22.10
  - python 3.7

This new loki version supports parsing multi-line logs, as demonstrated in
the updated test.

Since this version we also remove cache at the end of build, which
makes the software directory smaller and accessorily prevent test failures
during the ldd checks from checkSoftware with some binaries in the cache.

https://github.com/zopefoundation/ZEO/commit/503dccb1

We upgraded ZEO5 to 5.2.2 in commit 34ebf8b5 (ZEO5: v↑ (5.2.0 -> 5.2.2)), and
so now it works with msgpack 0.6.2 provided by stack/slapos.cfg.

The component remains on wendelin.core 1, but the build environment is
adjusted so that both (any of) wendelin.core 1 or wendelin.core 2 could
be built:

- Add zodbtools that wendelin.core 2 requires,
- Add Go and zlib to gowork that are neede to build WCFS.

GOPATH is going to go away in Go 1.17 and most of in-tree SlapOS things are
already built using modules - including upcoming wendelin.core 2 that also
builds/uses NEO/go. This way maintaining GOPATH-based approach becomes just
unneccesary burden (modulo development, where it is still needed sometime
unfortunately https://github.com/golang/go/issues/37755#issuecomment-771927771)

What was "latest" in 2018 is outdated by now.
-> Just use the versions that is provided by component/wendelin.core that neotest extends from.

Add support for using Go modules to golang/gowork infrastructure:

- Users can now request to install a module via gowork:install as. e.g.
  in the following example:

        [gowork]
        install =
            lab.nexedi.com/kirr/neo/go/...@v0.0.0-20210103165133-f3effa6c535f
            golang.org/x/tools/gopls@v0.4.3
            ${helloweb:location}/go:./...

  The first two request to install programs from an external module at particular
  revision/version. The latter requests to install programs from locally
  cloned/checked-out module source.

  The documentation now talks only about programs, because "package
  installation" became unnecessary long time ago as Go toolchain uses
  right packages and recompiles things as needed automatically since
  introduction of the Go build cache in go 1.10.

- The change comes accompanied by corresponding helloweb change that
  reworks it to a) become a module itself, and b) to use other modules -
  that are not explicitly cloned by buildout - so that we can be sure
  that module way of fetching/building things actually works.

  helloweb@a7c788ae

- Non-module way - e.g. build via GOPATH - is still supported (because
  e.g. software/gitlab still uses it), but not explicitly documented and 
  scheduled to be deprecated and removed. The reason for this is that
  upstream Go is going to remove support for GOPATH and leave only
  module-based approach in Go1.17

  https://github.com/golang/go/issues/37755#issuecomment-771879911

/cc @jerome, @luke, @tomo, @alain.takoudjou
/reviewed-on nexedi/slapos!924

Add support for using Go modules to golang/gowork infrastructure:

- Users can now request to install a module via gowork:install as. e.g.
  in the following example:

	[gowork]
	install =
	    lab.nexedi.com/kirr/neo/go/...@v0.0.0-20210103165133-f3effa6c535f
	    golang.org/x/tools/gopls@v0.4.3
	    ${helloweb:location}/go:./...

  The first two request to install programs from an external module at particular
  revision/version. The latter requests to install programs from locally
  cloned/checked-out module source.

  The documentation now talks only about programs, because "package
  installation" became unnecessary long time ago as Go toolchain uses
  right packages and recompiles things as needed automatically since
  introduction of the Go build cache in go 1.10.

- The change comes accompanied by corresponding helloweb change that
  reworks it to a) become a module itself, and b) to use other modules -
  that are not explicitly cloned by buildout - so that we can be sure
  that module way of fetching/building things actually works.

  kirr/helloweb@a7c788ae

- Non-module way - e.g. build via GOPATH - is still supported (because
  e.g. software/gitlab still uses it), but not explicitly documented and
  scheduled to be deprecated and removed. The reason for this is that
  upstream Go is going to remove support for GOPATH and leave only
  module-based approach in Go1.17

  https://github.com/golang/go/issues/37755#issuecomment-771879911

Some software releases - e.g. wendelin.core - only use ${go:exe} and
does not put anything into ${gowork:install}.

Put emphasis on that gowork defines Go workspace and explain first
settings that are related to that definition. Only after that say how to
use gowork.install. The reason for this is that gowork.install will
become optional in the next patch.

gowork.cfg idea is to specify a GOPATH snapshot with a list of
repositories and their revisions. GOPATH way of building things is going
to go away and we'll soon switch default mode to build go things to do
so via Go modules.

Refactor helloweb a bit before doing that as a preparatory step.

This allows factorising its version pins.

Update PEM to the latest available version.

test we can actually log in to repman and that hte monitoring API report
a cluster as up

no need to stick to an old EOL version

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

Since gmp is used by nft and nft is used by firewalld which is included
in slapos-node package, we need to have support for all CPU (disable-assembly).
Otherwise, you can see this kind of errors in dmesg:

firewalld[16932] trap invalid opcode ip:7f5f26ad61fb sp:7fff95cf7480 error:0 in libgmp.so.10.3.1[7f5f26ac7000+51000]

Note that --host=none-pc-linux-gnu is needed to enable the shared libraries.

We need the newest version anyway and it does not trigger a problem in OBS

Changes:
- Add comments and reorganise instance.cfg.in for clarity
- Select free ports instead of hardcoded ports
- Upgrade to slapos.core 1.6.5 to prefix forwarded requests

This makes it possible to recursively nest theias into theias.

See merge request nexedi/slapos!919

Consider a Go package that is defined via go-git-package, for example

    [helloweb]
    <= go-git-package
    go.importpath = lab.nexedi.com/nexedi/helloweb
    repository    = https://lab.nexedi.com/nexedi/helloweb.git

Currently, since go-git-package references ${gowork:src}, it creates
helloweb -> gowork dependency. gowork, in turn, depends on
gowork.goinstall, which gets list of things to install from ${gowork:install}.

Currently we put only plain strings into ${gowork.install}, e.g.

    [gowork]
    install =
       lab.nexedi.com/nexedi/helloweb/go/...

but for Go modules support and for properly expressing what depends on what,
we'll want in the next patch to be able to specify something like

    [gowork]
    install =
       ${helloweb:location}/go:./...

which will create helloweb ⇄ gowork cycle.

Unfortunately buildout does not detect nor report an error for such cycles, and
simply processes parts in an order, which leads to situation where e.g.
helloweb was not yet cloned, but gowork.goinstall tries to `go install` it and
complains "no such helloweb directory".

-> Fix it by leaving gowork to use by component/golang/ users, and putting
settings about where gowork directories is into underlying gowork.dir section.

Not sure which commit broke it, but this diff is now polluting my commits.

GOPATH is going to be removed in Go1.17 (see e.g. https://github.com/golang/go/issues/37755#issuecomment-771879911).

-> Prevent programs suddenly become installed into $HOME/go/bin instead of
gowork/bin, and mod cache to become something like $HOME/go/... instead of
being kept under gowork/

No change in behaviour for Go ≤ 1.16

This reverts commit 685f611d partially
because it breaks Mroonga (https://github.com/mroonga/mroonga/pull/394).
It's not so urgent to upgrade MariaDB so let's wait for a new release
of Mroonga.

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

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

Since this Go release switches GO111MODULE default from "auto" to "on", but we
still have in-tree GOPATH-mode uses, add GO111MODULE=auto to our goenv.sh to
preserve previous behaviour for now.

Don't drop support for Go1.14, Go1.13, Go1.12 yet, as that no longer supported
Go releases are still being used by in-tree components(*).

Remain default at Go1.15 yet.

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

(*) theia, caddy, galene, replication-manager, restic, gitlab and grafana

Go1.14 is end-of-life by today as it will no longer be updated after Go1.16 was
released in Feb 2021:

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

Go1.15 is current oldstable - i.e. it is still supported and mature.

Going Go1.14.12 -> Go1.14.15 brings in fixes to compiler, runtime, standard
library and build security.

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

Tested on helloworld SR (by adjusting it to use go1.14 instead of go1.15)

Go1.14.15 is the last Go1.14.x release, because, after Go1.16 was released, Go1.14
becomes end-of-life and will not receive any updates nor fixes for security bugs.

/cc @jerome (for theia which is on go1.14)
/cc @luke (for caddy which is on go1.14)

/cc @tomo, @alain.takoudjou (for galene which is still on EOL go1.13)
/cc @alain.takoudjou (for replication-manager which is still on EOL go1.13)
/cc @alain.takoudjou (for restic which is still on EOL go1.13)

/cc @jerome, @alain.takoudjou (for gitlab which is still on EOL go1.12)
/cc @jerome (for grafana which is still on EOL go1.12)

Going Go1.15.5 -> 1.15.8 brings in fixes to compiler, runtime, standard library
and build security.

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

Tested on helloworld SR.

* Update md5sum
* Add extra egg plone command

This brings in the following changes:

- nxdtest@1e6a1cc6
- nxdtest@b5a74214

The first one makes nxdtest more robust to detect an error in its worker
thread, while the second one makes nxdtest more human-friendly when used
while developing.

/reviewed-by @jerome
/reviewed-on !918

buildout has no knowledge of setup_requires, when installing a package with
setup_requires, setuptools will fetch the package from pypi and install its latest
version, regardless of buildout's versions or allow-picked-versions options, that
are critical for us to ensure repeatability.

These patches were produced by running buildout with a modified setuptools version which does not install setup_requires ( jerome/setuptools@54f42c38 ) and by modifying the profiles to use setup-eggs option in all the sections installing packages using setup_requires.

See merge request nexedi/slapos!912