Add client/server compatibility tests

[JeromeJu]

This issue tracks the improvement of upgrade test for preventing regression as noted in #5193:

Recently, we have had a few issues of regressions that were not detected by CI.

For example, https://github.com/tektoncd/pipeline/pull/4834 introduced changes that caused a new client to be incompatible with an old server.

In addition, some breaking changes were introduced where resources already stored on a cluster became invalid when the server version was upgraded. https://github.com/tektoncd/pipeline/pull/4779 added new defaults via the mutating webhook, and then https://github.com/tektoncd/pipeline/pull/4818 validated the existence of these defaults. However, existing resources didn't receive these defaults, so they failed validation.

We should add a step where we run integration tests on the older server version (before upgrading the server). This will address the first type of regression detailed here. When we do make a breaking change purposefully (after deprecating a field), I would imagine we'd remove tests for this functionality, so I don't think adding this check would stop us from removing deprecated fields.

• duplicate: [x] Add upgrade tests against e2e tests from previous releases #6728
• followup: to add LTS and supported releases for the e2e tests

[JeromeJu]

/assign

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/lifecycle frozen

[dibyom]

the first type of regression detailed here.

@JeromeJu could you describe what the regression we are trying to catch is?