Remove support for the legacy etcd provider as of k8s 1.18

[johngmyers]

This proposes to remove support for the legacy etcd provider for clusters running Kubernetes 1.18 or later.

[olemarkus]

I am all for getting rid of the legacy etcd provider, but isn't it better to do this based on kops version instead of k8s version? There is nothing in k8s that requires dropping legacy etcd, and as a user, it is always confusing when the k8s version is what determines what kops functionality is supported. I would rather go for a deprecation in kops 1.17 and removal in kops 1.19 or something. that will also let us get rid of the code. If we base it on k8s version, we'll be still stuck with the code "forever".

[johngmyers]

This is in line with the pattern of not making substantial changes in behavior to existing clusters until those clusters upgrade Kubernetes. Eventually kops will drop support for Kubernetes 1.17 and the legacy manager code will then be removed.

[johngmyers]

Conflicts with #8614 and want that PR to go in first because it is going to be cherrypicked.
/hold

[johngmyers]

/hold cancel

[johngmyers]

/retest

[rifelpet]

I see validateEtcdVersion still defaults to components.DefaultEtcd2Version if the version field isn't set. I wonder if it should be updated to 3.X but that can be its own PR.

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: johngmyers, 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 [rifelpet]

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

[rifelpet]

/retest

quay...

[hakman]

quay says they fixed it :)
/retest