Deprecation of the kubeadm config upload command

[Klaven]

/kind cleanup

What this PR does / why we need it:
This PR deprecates the kubeadm config upload command and all of it's sub-commands as a replacement in the form of kubeadm init phase upload-config.

Which issue(s) this PR fixes:
refs #kubernetes/kubeadm#988

Special notes for your reviewer:
Note: I tested cobra and it did not appear that "deprecated" was inherited from the parent command necessitating deprecating the individual sub commands as well.

I thought the comments in the code where nice for anyone browsing the code... but could be labeled a distraction and wasted space. not sure your all preference on that.

Does this PR introduce a user-facing change?:

Deprecates the kubeadm config upload command as it's replacement is now graduated. Please see `kubeadm init phase upload-config`

[Klaven]

/assign @rosti

[yagonobre]

Thanks!
/lgtm
/priority important-longterm

[neolit123]

/priority backlog

[neolit123]

just wanted to note that potential consumers of this variant would need to migrate to file only.
also that we need to have this deprecated for 12 months as GA functionality.
cc @rosti

[Klaven]

@neolit123 do you want me to put that in the above deprecation message?

[neolit123]

let's wait on rosti's comments.

[rosti]

This is actually the worst of them all. You don't get to see what's getting uploaded and users can easily mistake this to "patch" sort of command. Thus, they can inadvertently set some fields of their ClusterConfiguration to defaults and not even notice it.

[Klaven]

/test pull-kubernetes-e2e-gce

[rosti]

Thanks for this @Klaven !

I don't think, that there are that many users of kubeadm config upload from-flags, so I don't think, that we should put that much effort in it. At best, if users voice concerns for lack of instructions, we can document on the website how to download their current ClusterConfiguration (with kubectl) and then supply that to the init phase.

@Klaven just a tiny nit, can you change "Fixes" to "Refs" so that the original issue does not get closed upon merge? I want to reuse it to track there the fact that we want to remove the commands after about an year. Ping me when this is done to remove the hold.

/approve
/hold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Klaven, rosti

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:

• cmd/kubeadm/OWNERS [rosti]

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

[rosti]

/hold cancel