CRI-O config (/etc/crio/crio.conf) should not be hardcoded (nor overwritten without a prompt)

[intelfx]

With minikube start --vm-driver=none --container-runtime=crio, minikube attempts to overwrite any pre-existing CRI-O configuration at /etc/crio/crio.conf with a hardcoded template.

First, this has a potential for user data loss (if the user has a nontrivial configuration in place).

Second, this makes minikube/crio unusable on any systems that do not adhere to the hardcoded paths (e. g. Arch Linux, which has /usr/bin/conmon and /usr/lib/cni instead of /usr/libexec/crio/conmon and /opt/cni/bin).

Finally, this makes it impossible to use any container runtime other than crun (which is often the motivation to use CRI-O in the first place).

[afbjorklund]

This is related to #5677 (about the template). Data loss is to be expected when using the "none" driver, but there is also compatibility issues with different crio versions and the afforementioned paths.

[afbjorklund]

This already overwrites the configuration from the ISO as well, so the crio.conf in the Buildroot package is not what ends up being used... To make matters worse, crio.conf is in "cri.go" and not in "crio.go".

[afbjorklund]

Removed the hard-coded configuration, now only updating the pause_image.

See #6219