Add antctl CLI command to run pre-installation sanity checks

[antoninbas]

This is a subtask for #5896

Regardless of the installation method for Antrea, it would be useful to have an antctl CLI command to quickly validate that a K8s cluster is ready for Antrea installation.

Some ideas we had for pre-installation sanity checks:

• check K8s version (should be >= 1.19)
• check if another CNI is present; we can look for them by name (Cilium, Calico, Weave, Flannel)
• Node checks (Linux):
  • check the Kernel version; @tnqn pointed out that this may be tricky with some distros such as RHEL (see https://github.com/antrea-io/antrea/blob/main/docs/getting-started.md#open-vswitch)
  • check if openvswitch Kernel module is either built-in or loadable; see:

    antrea/build/images/scripts/install_cni

    Lines 61 to 65 in c2f2459

    	if ! is_module_builtin "openvswitch"; then
    	modprobe openvswitch || (echo "Failed to load the OVS kernel module from the container, try running 'modprobe openvswitch' on your Nodes"; exit 1)
    	else
    	echo "Module openvswitch is built-in"
    	fi

• check if NodeIPAM is enabled in kube-controller-manager (see https://github.com/antrea-io/antrea/blob/main/docs/getting-started.md#nodeipam); if not it is not a "fatal" error but user should be warned that the default configuration will not work
• check if the K8s API aggregation layer is enabled (https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/); if not, warn user that some features will not work as expected
• check if the K8s control plane is running "outside" the K8s cluster (no control plane Nodes): if yes, warn use that some features will not work as expected in the default Antrea configuration

@tnqn @luolanzone feel free to add some ideas as well

Ideally, this CLI command would belong to the same top-level command group as the "post-installation" command (#6061).

[antoninbas]

cc @kanha-gupta

[tnqn]

check if another CNI is present; we can look for them by name (Cilium, Calico, Weave, Flannel)

Perhaps we can just check this by ensuring no conf in /etc/cni/net.d/ will take priority over 10-antrea.conflist, which could generally work for all CNIs. Also, even if there is no DaemonSet running for other CNIs, container runtime will not invoke antrea unless the config file is the 1st in alphabetical order. I handled several cases that users said pod network is not working after installing antrea then it turned out that there was a stale CNI config in /etc/cni/net.d/ even though there was no running DaemonSet for that CNI.