Update go19 and go18 to their latest upstream versions bringing up bug and
security fixes.

Go19 tested briefly on neotest run.

/reviewed-by TrustMe

For example one could want to build the software with race detector,
e.g.

	[gowork]
	...
	buildflags = -race

or if you want to build a plugin for fluent-bit

	[gowork]
	...
	install	   = your.package.import.path
	buildflags = -buildmode=c-shared

and then your package will be installed as shared library into

	${gowork:directory}/pkg/`go env GOOS`_`go env GOARCH`/<your.package.import.path>.a

One could pass that location explicitly to `fluentd-bit -e ...` or
symlink to it from some .so from global directory of fluent-bit plugins.

Maybe it is not very good to use `go install` for building plugins
(instead of `go build -o ...`) but we anyway need to have ability to
specify buildflags as a generic feature, hence this patch.

/reviewed-on nexedi/slapos!274

My mistake from 1b540151 (golang: Infrastructure to build Go workspaces / projects)

/reviewed-by TrustMe

On some machines, net:TestDialTimeout never passes and today, Go 1.4 is only
used for bootstrapping, so let's not be more clever than Go devs, who
explicitly state to use make.bash

See also https://github.com/golang/go/issues/18954

Version up for golang from go1.9.1 to go1.9.2

@rafael @kirr @alain.takoudjou

[ kirr: from https://golang.org/doc/devel/release.html#go1.9.minor

go1.9.2 (released 2017/10/25) includes fixes to the compiler, linker, runtime, documentation, go command, and the crypto/x509, database/sql, log, and net/smtp packages. It includes a fix to a bug introduced in Go 1.9.1 that broke go get of non-Git repositories under certain conditions. See the Go 1.9.2 milestone on our issue tracker for details.

@gabriel says they tested go1.9.2 on Caddy ]

/reviewed-on nexedi/slapos!247

[golang14] fix TestParseInLocation test: Install package from latest changes on upstream go14 branch

https://github.com/golang/go/commit/4d5426a570c2820c5894a61b52e3dc147e4e7925

golang14 is still failing to build on some server, the commit above fix the
problem on test TestParseInLocation. This is why we install golang14 from upstream go14 branch.

[ kirr: see also relateddiscussion on nexedi/slapos!133 ]

/reviewed-by @kirr
/reviewed-on nexedi/slapos!245

In Go world development workflow is organized around so-called workspace
where multiple packages can be installed / worked on etc. The following
page describes Go workspaces:

https://golang.org/doc/code.html

A new [gowork] section and infrastructure around it is introduced.
Quoting code:

    # gowork is a top-level section representing workspace
    #
    # users should add `install` field to [gowork] to describe packages they want to
    # be installed (+ automatically their dependencies are installed too). e.g.
    #
    #   [gowork]
    #   install =
    #       lab.nexedi.com/kirr/neo/go/...  \
    #       github.com/pkg/profile          \
    #       golang.org/x/perf/cmd/benchstat

The way it all works inside is:

- gowork organizes to create go.work/ directory in buildout root
- inside it creates env.sh which when sources in shell adjusts all paths
  so that appropriate go compiler is in path, GOPATH is also set
  appropriately, etc - in other words everything needs for using/working
  on this workspace is setup in the environment.
- in actual user software profile the list of Go projects which needs to
  be installed by SlapOS has to be listed. The [gowork] machinery takes
  care about git-cloning these projects and `go install`s them after.
- by SlapOS design builds have to be reproducible and so every component
  state/version has to be fixed.

  A convenient helper (gowork-snapshot) to get snapshot of git go
  packages installed with their exact revisions is added. This should be
  used to automatically (re-)generate list of go git repositories &
  their pinning for a workspace.

For a new Go project that needs to be slaposified the workflow should be:

- first get a project into working state via any convenient way (`go get`, etc.)
- generate list of go packages & their pinning with gowork-snapshot
- extend golang/buildout.cfg and in project software profile add

	[gowork]
  	install = your-top-level-packages

  as it was outlined above.

P.S.

[golang] is removed because

1. it is not used anywhere in slapos.git tree, and
2. the canonical way to work on go projects from now on will be to use
   [gowork]. There latest go version is preconfigured, but users can
   override it to some particular other version in their projects as they
   need.

/reviewed-on	 !242
/also-needed-for !243

Go1.5 and go1.6 are not used anywhere in slapos tree and neither these versions are supported by upstream release policy https://golang.org/doc/devel/release.html#policy anymore. So let's remove them.

1.8.X is current stable series of Go.

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

Besides many other significant improvements it should now also support ARM64.

/cc @jp
/reviewed-by TrustMe  (tested on helloworld)

Otherwise it started to fail this way:

[2017-02-22 11:49:22,982] INFO     --- FAIL: TestLoadFixed (0.00s)
[2017-02-22 11:49:22,982] INFO          time_test.go:929: Now().In(loc).Zone() = "-01", -3600, want "GMT+1", -3600
[2017-02-22 11:49:22,983] INFO     FAIL
[2017-02-22 11:49:22,983] INFO     FAIL time    2.380s

See https://github.com/golang/go/issues/16352#issuecomment-255835099 and around
for details.

From upcoming https://golang.org/doc/devel/release.html#go1.6.minor

    go1.6.3 (released 2016/07/17) includes security fixes to the net/http/cgi
    package and net/http package when used in a CGI environment. This release also
    adds support for macOS Sierra.  See the Go 1.6.3 milestone[1] on our issue
    tracker for details.

    [1] https://github.com/golang/go/issues?q=milestone%3AGo1.6.3

/reviewed-by TrustMe    (tested with helloworld)

1.6.X is current stable series of Go.

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

So switch helloweb and default golang to it.

/reviewed-by TrustMe  (tested on helloworld)

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

    go1.5.4 (released 2016/04/12) includes two security fixes. It contains
    the same fixes as Go 1.6.1 and was released at the same time. See the Go
    1.6.1 milestone[1] on our issue tracker for details.

    [1] https://github.com/golang/go/issues?q=milestone%3AGo1.6.1

/reviewed-by TrustMe    (tested with helloworld)

This is a security-bugfix release:

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

    go1.5.3 (released 2016/01/13) includes a security fix to the math/big
    package affecting the crypto/tls package. See the Go 1.5.3 milestone on
    our issue tracker[1] and the release announcement[2] for details.

    [1] https://github.com/golang/go/issues?q=milestone%3AGo1.5.3
    [2] https://golang.org/s/go153announce

I've rebuild helloworld software release and briefly tested helloweb.go
with go 1.5.3 ok.

/reviewed-by: TrustMe
/cc @kazuhiko, !39

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

    go1.5.2 (released 2015/12/02) includes bug fixes to the compiler,
    linker, and the mime/multipart, net, and runtime packages

/reviewed-by: TrustMe

Add support for Go language in the form of providing component for Go
toolchain and stdlib.

Current Go stable series is 1.5.* but to bootstrap it one need to have
Go 1.4.* available, which itself needs C compiler to bootstrap.

We need Go support for upcoming GitLab SR, where one server is written
in this language:

    https://gitlab.com/gitlab-org/gitlab-workhorse

/cc @gabriel, @Camata