Incorporate e2e k8s lib update as part of the controller release workflow

[mtulio]

What would you like to be added:

Feature to component: release workflow / e2e test framework

Incorporate the e2e test binary (code in tests/e2e) to the release cycle updating the k8s dependencies.

Currently the e2e test binary (backed by ginkgo) are using old k8s library dependencies, such as:

cloud-provider-aws/tests/e2e/go.mod

Lines 11 to 15 in de9a0ab

	k8s.io/api v0.26.0
	k8s.io/apimachinery v0.26.0
	k8s.io/client-go v1.5.2
	k8s.io/kubernetes v1.26.0
	k8s.io/pod-security-admission v0.26.0

Highlight to the k8s/client-go@1.5.2 released in 2021!

Why is this needed:

It would be nice to have the e2e test binary k8s dependencies following the version skew of controller dependencies, so that the test framework will be enhanced with core updates frequently (minor release basis) inheriting bug and security fixes, and features incorporated to core, as well tracking API deprecation which requires test review, or ginkgo improvements.

What do you all think? Would be possible to bump tests/e2e with controller, let's say in a minor release cycle?

/kind feature

[k8s-ci-robot]

This issue is currently awaiting triage.

If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mtulio]

Hey @kmala @elmiko , WDYT about this approach? I can help bumping to the existing version, but would like to hear from you if you see value on incorporating as part of the controller release flow.

[elmiko]

+1 from me, i think we should be updating the e2e test configs whenever we bump the k8s, or any core, dependencies.