Recommended update for go1.17

This update for go1.17 fixes the following issues:

This is the initial go 1.17 shipment.

go1.17.1 (released 2021-09-09) includes a security fix to the
archive/zip package, as well as bug fixes to the compiler,
linker, the go command, and to the crypto/rand, embed, go/types,
html/template, and net/http packages. (bsc#1190649)

CVE-2021-39293: Fixed an overflow in preallocation check that can cause OOM panic in archive/zip (bsc#1190589)

go1.17 (released 2021-08-16) is a major release of Go.

go1.17.x minor releases will be provided through August 2022.

See https://github.com/golang/go/wiki/Go-Release-Cycle

Most changes are in the implementation of the toolchain, runtime,
and libraries. As always, the release maintains the Go 1 promise
of compatibility. We expect almost all Go programs to continue to
compile and run as before. (bsc#1190649)

* See release notes https://golang.org/doc/go1.17. Excerpts
relevant to OBS environment and for SUSE/openSUSE follow:
* The compiler now implements a new way of passing function
arguments and results using registers instead of the
stack. Benchmarks for a representative set of Go packages and
programs show performance improvements of about 5%, and a
typical reduction in binary size of about 2%. This is currently
enabled for Linux, macOS, and Windows on the 64-bit x86
architecture (the linux/amd64, darwin/amd64, and windows/amd64
ports). This change does not affect the functionality of any
safe Go code and is designed to have no impact on most assembly
code.
* When the linker uses external linking mode, which is the
default when linking a program that uses cgo, and the linker is
invoked with a -I option, the option will now be passed to the
external linker as a -Wl,--dynamic-linker option.
* The runtime/cgo package now provides a new facility that allows
to turn any Go values to a safe representation that can be used
to pass values between C and Go safely. See runtime/cgo.Handle
for more information.
* ARM64 Go programs now maintain stack frame pointers on the
64-bit ARM architecture on all operating systems. Previously,
stack frame pointers were only enabled on Linux, macOS, and
iOS.
* Pruned module graphs in go 1.17 modules: If a module specifies
go 1.17 or higher, the module graph includes only the immediate
dependencies of other go 1.17 modules, not their full
transitive dependencies. To convert the go.mod file for an
existing module to Go 1.17 without changing the selected
versions of its dependencies, run: go mod tidy -go=1.17
By default, go mod tidy verifies that the selected versions of
dependencies relevant to the main module are the same versions
that would be used by the prior Go release (Go 1.16 for a
module that specifies go 1.17), and preserves the go.sum
entries needed by that release even for dependencies that are
not normally needed by other commands.
The -compat flag allows that version to be overridden to
support older (or only newer) versions, up to the version
specified by the go directive in the go.mod file. To tidy a go
1.17 module for Go 1.17 only, without saving checksums for (or
checking for consistency with) Go 1.16: go mod tidy
-compat=1.17
Note that even if the main module is tidied with -compat=1.17,
users who require the module from a go 1.16 or earlier module
will still be able to use it, provided that the packages use
only compatible language and library features.
The go mod graph subcommand also supports the -go flag, which
causes it to report the graph as seen by the indicated Go
version, showing dependencies that may otherwise be pruned out.
* Module deprecation comments: Module authors may deprecate a
module by adding a // Deprecated: comment to go.mod, then
tagging a new version. go get now prints a warning if a module
needed to build packages named on the command line is
deprecated. go list -m -u prints deprecations for all
dependencies (use -f or -json to show the full message). The go
command considers different major versions to be distinct
modules, so this mechanism may be used, for example, to provide
users with migration instructions for a new major version.
* go get -insecure flag is deprecated and has been removed. To
permit the use of insecure schemes when fetching dependencies,
please use the GOINSECURE environment variable. The -insecure
flag also bypassed module sum validation, use GOPRIVATE or
GONOSUMDB if you need that functionality. See go help
environment for details.
* go get prints a deprecation warning when installing commands
outside the main module (without the -d flag). go install
cmd@version should be used instead to install a command at a
specific version, using a suffix like @latest or @v1.2.3. In Go
1.18, the -d flag will always be enabled, and go get will only
be used to change dependencies in go.mod.
* go.mod files missing go directives: If the main module's go.mod
file does not contain a go directive and the go command cannot
update the go.mod file, the go command now assumes go 1.11
instead of the current release. (go mod init has added go
directives automatically since Go 1.12.)
If a module dependency lacks an explicit go.mod file, or its
go.mod file does not contain a go directive, the go command now
assumes go 1.16 for that dependency instead of the current
release. (Dependencies developed in GOPATH mode may lack a
go.mod file, and the vendor/modules.txt has to date never
recorded the go versions indicated by dependencies' go.mod
files.)
* vendor contents: If the main module specifies go 1.17 or
higher, go mod vendor now annotates vendor/modules.txt with the
go version indicated by each vendored module in its own go.mod
file. The annotated version is used when building the module's
packages from vendored source code.
If the main module specifies go 1.17 or higher, go mod vendor
now omits go.mod and go.sum files for vendored