Stop changing istio during upgrade/downgrade testing

[mattmoor]

In what area(s)?

/area networking
/area test-and-release

What version of Knative?

HEAD

Expected Behavior

Upgrade and downgrade testing should just change Knative. Hitless Istio upgrades are Istio's problem.

Actual Behavior

Our upgrade testing regularly hits problems fixed in our HEAD istio configuration (e.g. NodePort has seen a huge rash of failures, hitting this almost a half dozen times).

Steps to Reproduce the Problem

Run the upgrade test, watch Istio change.

/assign @adrcunha

I think @jonjohnsonjr indicated that this was a regression(?), and that he was struggling to wade through the bash to fix this.

[duglin]

It seems to me that if our recommended version of Istio changes between our releases then we should test that the old kn+istio install can be upgraded to the new kn+istio versions per our docs.

[mattmoor]

To clarify: I'm totally fine with testing multiple versions of Istio, in fact I want us to be testing: 1.0 (mesh), 1.0 ("lean"), 1.1 (mesh), 1.1 ("lean"); though probably one of those presubmit. (The same infrastructure should be used to test community plugins like Gloo's)

However, regardless of whether we document a particular version of Istio or not, it is simply not in scope for Knative and useless noise when the following flake during e2e tests:

1. Istio install
2. Istio updates (incl. "hitless")

As a datapoint, in our very red continuous build well over a dozen of the failures are a "node port" collision that's long been fixed at head. At the moment, this is the single biggest contributor to e2e flakes by probably an order of magnitude.

[mattmoor]

I believe all we have to do is change these two lines to use these env vars.

/assign @jonjohnsonjr
/unassign @adrcunha