Unfreeze Rancher version to install stable releases

[nikkelma]

The version of Rancher installed by the quickstart should follow the stable release channel. As suggested by @chrisurwin, instead of locking the version to a default in the variables, allow specifying a version of Rancher but use the most recent chart from rancher-stable (https://releases.rancher.com/server-charts/stable).

[nikkelma]

There are two options for keeping the quickstart version in line with the stable release channel:

1. Lock variables specifying versions to the known current stable release and use this in the helm installation process, changing default versions through PRs (and testing each PR to confirm a successful deployment).

   • This requires issues and/or PRs to update the version of Rancher used; if these are not resolved quickly, there will be a window of time where the Rancher version will fall behind the current stable release.

2. Don't specify a version for the rancher helm release by default, just use rancher-stable's latest version unless overridden by a variable.

   • This requires issues and/or PRs to fix a broken deployment; if these are not resolved quickly, there will be a window of time where the quickstart will not result in a successful deployment.

For historical context, 2 was implemented previously, but the RKE + Rancher + Helm terraform refactor (e37bdb8) switched to 1. This switch was made because the required version of cert-manager changed throughout the 2.3.x releases, meaning the quickstart could have broken without any code changes. Finally, looking through issue and PR history shows this repo has gone dormant before and PRs have been left idle for up to a year even when active development was occurring.

I'd love discussion on stability vs. maintenance overhead. As the current primary maintainer, I'd rather have confidence in a working setup that requires some occasional attention, as opposed to a setup that requires a quick response.

I'm biased though, so all input is much appreciated.

[nikkelma]

Had some internal discussions around this topic with other Rancher FEs. If I understand our resolution, the path forward looks like following Rancher best practices to pin the version used, but develop automation to validate new versions (following the latest channel) to confirm successful deployments (great idea @bashofmann!). This automation would create issues for versions of Rancher that fail to deploy, allowing for code changes to be made and validated before latest becomes stable.

Prerequisites include creating a docker image (#76) and developing tests (#77).

[nikkelma]

Wanted to note a discovery: according to this commit, cert-manager versions were upgraded from 0.9 to 0.12 in December 2019, right before a wave of releases including this in their release notes (for example, v2.3.4). Some internal discussions claimed only 2.4 had changes for cert-manager versions, glad this gives a concrete example of the possibility for instability.