KCP: Handle kube-proxy upgrades

[vincepri]

This issue is a follow-up to #2226.

• add code to KCP controller to update the kube-proxy DaemonSet in the workload cluster to match KCP.spec.version
• images must be pullable (public or private registry), as the DaemonSet applies to all nodes in the workload cluster, and the OS images from which they booted won't have version n (current version) and n+1 (new version) both preloaded
• we may need code in KCP controller to wait to update the DaemonSet until all machines (control plane and workers) are at least the same minor version or even patch version (e.g. don't want a 1.18 control plane, 1.17 worker nodes, and bump all kube-proxy pods to 1.18)

/kind feature
/milestone v0.3.0
/priority critical-urgent
/area control-plane

[vincepri]

cc @detiber @sedefsavas

[randomvariable]

kubeadm would typically bump the kube-proxy daemonset during the control plane upgrade, so maybe in the first instance don't need to do the final bullet point?

at some point, would also need to account for clusters not running kube-proxy where that feature is implemented in the CNI. Calico is about to head in this direction (has experimental support for replacing kube-proxy with itself today)

[detiber]

at some point, would also need to account for clusters not running kube-proxy where that feature is implemented in the CNI. Calico is about to head in this direction (has experimental support for replacing kube-proxy with itself today)/

It should be pretty easy to skip the logic if the kube-proxy daemonset doesn't exist.

[sedefsavas]

/assign

/lifecycle active