Update to go1.17

[ialidzhikov]

/area open-source
/kind enhancement

This PR consists of the following parts:

1. Update of the go version in the Dockerfile
2. Update of the go version in the TestDefinitions
3. make generate changes caused by gofmt that synchronizes //go:build lines with // +build lines - ref https://golang.org/doc/go1.17#gofmt
4. make format for the ./hack dir to synchronizes the build lines there as well

I didn't update the go version of the module (the one in go.mod) because to be honest I am not able to completely follow the changes to the module graph pruning. go1.17 should be able to work with go1.16 module. This is actually also how kubernetes/kubernetes upgraded to go1.17 - the go runtime version is go1.17 but the module version is still go1.16 - ref kubernetes/kubernetes#103692. So it should not be a problem if we delay to module version update to another PR.

TODOs before merging this:

• Adapt branch.cfg to use go1.17 for the master branch and go1.16 for the release branches that still require go1.16 (and example commit with the adaptation - ialidzhikov@4200bf9) -> e204dee

TODOs after merging this PR:

• Update the go.mod to go1.17 -> Update the go.mod version to go1.17 #4843

Special notes for your reviewer:

• There is a breaking change in the net pkg - the ParseIP and ParseCIDR functions now reject IPv4 addresses which contain decimal components with leading zeros (ref https://golang.org/doc/go1.17#net). The change tackles the following CVE - https://nvd.nist.gov/vuln/detail/CVE-2021-29923.
  kubernetes/kubernetes decided to preserve the backwards compatibility and K8s will still allow IPv4 addresses that contain decimal components with leading zeros (ref golang 1.17 fails to parse IPs with leading zeros kubernetes/kubernetes#104368).
  So from a Gardener side it is a little bit tricky how to tackle this breaking change - from one side we have a breaking change, on the other side if we decide to take approach like kubernetes/kubernetes to preserve the compatibility we will be still affected by the high CVE. I decided to take the first approach and "accept the breaking change". But if someone has suggestions/objections, they are more than welcome.

Release note:

Since go1.17 both `net.ParseIP` and `net.ParseCIDR` reject leading zeros in the dot-decimal notation of IPv4 addresses. With the update to go1.17, gardener-apiserver now rejects Shoot objects with CIDR ranges that have such leading zeros in the dot-decimal notation. Before updating to this version of gardener-apiserver, make sure that there are no Shoot objects with leading zeros in the dot-decimal notation of an IPv4 address. For reference: https://nvd.nist.gov/vuln/detail/CVE-2021-29923

The golang version is now updated to `1.17.2`.

[timebertt]

I think, we need to decide, whether to merge this one or #4825 first, because it will conflict (see #4825 (comment))

[rfranzke]

/lgtm

TODOs after merging this PR:
Update the go.mod to go1.17

Can you open an issue for it? :)

[rfranzke]

@timebertt In the Daily we agreed to merge #4825 first and then @ialidzhikov can rebase this PR.

[ialidzhikov]

As expected the verify step will continue to fail until we update the branch.cfg to use go1.17 for the master branch.

@rfranzke can you check whether ialidzhikov/gardener@4200bf9 will do the trick for pipeline update for go1.17? Thanks in advance.

[rfranzke]

As expected the verify step will continue to fail until we update the branch.cfg to use go1.17 for the master branch.

@rfranzke can you check whether ialidzhikov/gardener@4200bf9 will do the trick for pipeline update for go1.17? Thanks in advance.

I think it looks good @ialidzhikov. Shall we go ahead merging this PR?

[ialidzhikov]

I think it looks good @ialidzhikov. Shall we go ahead merging this PR?

The PR looks fine to me. Thank you for checking the branch.cfg change and for the approval. I am in general not in a hurry with this PR. After merging this PR new verify runs of existing PRs will fail (they will need to rebase). So to make it 1 idea less breaking for the other PRs, I can proceed with it on Friday evening (when I don't expect a high ratio of PR updates). I first plan to update branch.cfg, then to retrigger the pipeline run and finally merge.

[rfranzke]

OK, sounds good, thank you very much!