Fix improper use of non-polling Eventually in tests

[vzdai]

Description

As discovered in kedacore#5962 (comment), the Eventually function of Gomega is meant to block when called and attempts an assertion periodically until it passes or a timeout occurs (docs).

This means we should be using it with polling functions such as Get to wait for an event to happen (example), but not functions such as Create unless we're intending to repeatedly try the creation until something different happens.

Our incorrect usage causes the existing tests to report false results, because in cases such as:

	Eventually(func() error {
		return k8sClient.Create(context.Background(), so)
	}).Should(HaveOccurred())

An error does occur here, but that's caused by the error resourceVersion should not be set on objects to be created since so gets modified in-place after the first create and we're trying to apply it again.

On the other hand, if we expect no error to occur with the create:

	Eventually(func() error {
		return k8sClient.Create(context.Background(), so)
	}).ShouldNot(HaveOccurred())

If the first Create passes, then the Eventually block also passes. In this case, there's no point having the Eventually since we're not waiting for anything.

Changes

As proof that this Eventually is not necessary and will only lead to false positives, I've tried removing the wrapper from all places where it's called with a mutating Create or Update call. With this change, the tests still pass.

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

Relates to #

[vzdai]

Validation for stabilizationWindowSeconds was added in kedacore#4983 via a validation patch directly on the CRD. It looks like the patch doesn't get picked up by the admission webhook, so the webhook actually thinks this is a valid object. This test is a false positive, and I don't think it belongs in this file with the rest of the admission webhook unit tests.

# error message when rejected by admission webhook
Error from server (Forbidden): error when creating "scaledobject.yaml": admission webhook "vscaledobject.kb.io" denied the request: type is cpu , but fallback it is not supported by the CPU & memory scalers

# error message when rejected by CRD validation
The ScaledObject "keda-test" is invalid: spec.advanced.horizontalPodAutoscalerConfig.behavior.scaleDown.stabilizationWindowSeconds: Invalid value: 36000: spec.advanced.horizontalPodAutoscalerConfig.behavior.scaleDown.stabilizationWindowSeconds in body should be less than or equal to 3600

I'm not sure how to test a direct CRD patch though so I haven't added a replacement test - need to look into it more, or open to suggestions here.