Allows specifying k3s version

[gmautner]

Remark: this PR had been previously approved in #1436 and then reverted in #1448 for a reason I believe was unrelated to the PR (k3s channel server outage). I’m resubmitting as asked to do so.

Sometimes a cluster operator might prefer to specify the k3s version (e.g. v1.29.6+k3s2) instead of the channel (e.g. v1.29, stable etc.)

Reasons for that could be not wanting the system upgrade controller to run at unpredictable times, or having more fine-grained control over the running version.

This PR introduces a new variable install_k3s_version in kube.tf. If undefined, the present behavior is preserved such that current installations are not affected. However, when defined, this variable takes precedence over initial_k3s_channel.

The mechanism for upgrades in either case continues to be the system upgrade controller.

The following scenarios were tested and worked according to expected:

• Created a new cluster with default settings and initial k3s channel was used
• Configured install k3s version on above cluster and plan was changed to refer to k3s version and executed properly
• Created a new cluster with install_k3s_version and it was installed with the desired k3s version
• Deleted install_k3s_version variable on above cluster, plan changed to use initial k3s channel instead and executed properly

[aleksasiriski]

LGTM