compute the compatibility versions instead of hardcode versions in test

[Icarus9913]

Description

We noticed that we have a hard-coded kuma version 2.6.10 in the 2.10.* or master test framework, which is out of date but we didn't noticed it:

kuma/test/framework/config.go

Lines 216 to 218 in de16dff

	Compatibility: CompatibilitySuiteConfig{
	HelmVersion: "2.6.10",
	},

Maybe we can use the versions.yml to calculate the current compatibility version.

[Icarus9913]

Another old hard-coded version 2.5.x releated code:

kuma/test/e2e/compatibility/cp_compatibility_kubernetes_multizone.go

Lines 114 to 118 in de16dff

	// then resource is synchronized to Global (The namespace here will need to be updated as soon as the minimum version is 2.5.x
	Expect(err).ToNot(HaveOccurred())
	Eventually(func() (string, error) {
	return k8s.RunKubectlAndGetOutputE(globalCluster.GetTesting(), globalCluster.GetKubectlOptions("kuma-system"), "get", "dataplanes")
	}, "30s", "1s").Should(ContainSubstring("demo-client"))

[lukidzi]

We currently run Helm upgrade E2E tests using the version defined in versions.yaml on a specific branch. We should consider improving this approach.

Ideas:

1. Use Helm to automatically determine the latest version(What about Universal mode in this case?)
2. Expose versions.yaml in the kuma-website, allowing us to fetch the latest versions on all branches.
3. Other suggestions…

[bartsmykla]

Triage: we should rely on the versions.json file available on the website