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

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.

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:

- nexedi/nxdtest@1e6a1cc6
- nexedi/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 nexedi/slapos!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

It does -X PUT + --data-binary @file.

It's available only on the slave, so it is not part of master partition
configuration.

Due to the cleanup change the parameter parsing logic has to be improved.

Improvements:

 * link from README to schemas
 * drop incorrect entries in README
 * improve entries description in README
 * make parameter description more understandable in SCHEMA

Instead of duplicating the versions and having an old pin to a version
which is now older than caucase minimum required version.

This reverts commit 16d90017
because new use of collective.recipe.template is forbidden.

use six for python3 compatibility

See merge request !914

See merge request !913

All CMF Products are using eggtestinfo as a setup egg (which is
no longer the case after 2.4.0)

Our schemas test check all files if they are present, but it so far it did not check
that the request and response schema referenced in software.cfg.json were really
existing and they were missing for some softwares.

This extends the test to check that request / response exists and add missing responses for cdn-me and srslte

See merge request nexedi/slapos!910

So that the test fail if they are missing.

monitor_v6_url and info_1 were not documented, monitor_v6_url is useless
since we have monitor_url and info_1 seems "self explanatory" for humans
and not targeted at machines.

also fix typo on publish-connection-informations