Upgrade to go 1.14.4

[rifelpet]

k/k 1.19 is using go 1.14.4 so this updates kops to match. kubernetes/kubernetes#88638

Using these PRs as a reference: #8882 #8886

Depends on #9428

also reverts #9396 since it is no longer needed (go 1.14's default behavior changed)

[rifelpet]

We may have to update the required statuses in test-infra which means any open PRs would need to rebase :/ unless we decide to drop the jobs being added/removed from being required for some period of time.

https://github.com/kubernetes/test-infra/blob/1771aee48e8d2e88811e71d50b18994d79e01f53/config/prow/config.yaml#L195-L202

what if, for a long term solution, we used a different term instead of the go version in the GHA job name? like:

• build (ubuntu-18.04, 1.13) -> build (linux, primary)
• build (ubuntu-18.04, 1.14) -> build (linux, secondary)
• build (macos-10.15, 1.13) -> build (darwin, primary)
• verify (ubuntu-18.04, 1.13) -> verify (linux, primary)

suggesting that we have a "primary" and "secondary" go versions. That way we can bump Go or OS versions without adjusting the required status contexts.

thoughts?

[johngmyers]

Using "primary"/"secondary" would have the consequence of allowing a merge based on a GHA job that ran with an older go version. That might be okay, since it's only macos where we don't have Prow coverage.

[rifelpet]

Yea that's true. I suppose we had the same limitation with Travis before GHA. Regardless I think we'll need to remove at least some of the GHA jobs from the required statuses and we'll need to wait some time before readding the new jobs' names in order to minimize disruption of other open PRs.

[johngmyers]

Certainly allowing merges based on runs with older Go versions is better than allowing merges with failed runs.

[rifelpet]

With #9552 merged this has been simplified a bit and is ready for review

[justinsb]

Not sure whether this should be mod or vendor? But I don't think it's a blocker.

[rifelpet]

We're not vendoring k8s.io/code-generator so I believe this was always installing from upstream or the module cache. It might be a good idea to vendor it by adding it to tools.go but that can happen in a followup PR.

[justinsb]

This LGTM, but I'm afraid there's a conflict on the makefile

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, rifelpet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb,rifelpet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hakman]

/lgtm

[hakman]

/retest