fix: fix failing webhook check when targetRef doesn't exist

[y-rabie]

The PR's intent is to fix a behavior whereby the SO creation fails when the targetRef object does not exist, which seems to be a byproduct of verifying that container resources are set, not an intentional check. The following are my reasons:

• To be similar to HPA's behavior, which doesn't fail when the targetRef object doesn't exist.
• This also makes sense through an eventual consistency lense: we shouldn't expect the SO to be always created before the Deployment/StatefulSet/etc.
• Also, currently if the target is not Deployment or StatefulSet, the container resouce check doesn't handle it, it just returns and doesn't error out even if the target doesn't exist, which corroborates the view that the target's existence is not what is intentionally checked.

Other few side changes:

• I've added logic to fail the case where the deployment does exist, and a cpu/memory trigger references a non-existent containerName, which seems to be a reasonable check. A corresponding unit test is also added.
• Some reordering of the unit tests in the file (the diff is a bit confusing 😄)
• A redundant unit test have been removed, the one of the two that were added for the LimitRange case. The first of which (where no LimitRange exist) is already covered in the above tests.
• An inner if condition on the trigger type within the verifyCPUMemoryScalers function is removed since it is duplicated.

The autogenerated code changes are not part of my changes, it just seems that they weren't generated for the latest change on main.

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)

[JorTurFer]

I like this improvement, but I think that we should expose the new behavior via configuration, WDYT @wozniakjan ?

[JorTurFer]

PTAL @kedacore/keda-core-contributors

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[JorTurFer]

PTAL @kedacore/keda-core-contributors @kedacore/keda-core-maintainers

[zroubalik]

I like this improvement, but I think that we should expose the new behavior via configuration, WDYT @wozniakjan ?

Yeah, I tend to agree with this.

[y-rabie]

@JorTurFer Configuration as in a field in ScaledObject, or a controller command-line option? I'm okay with the latter, the former not tbh because it'd just add clutter

[JorTurFer]

@JorTurFer Configuration as in a field in ScaledObject, or a controller command-line option? I'm okay with the latter, the former not tbh because it'd just add clutter

I think that as starting point, we can enable it as controller option at that's all, if end-users request more granular control, we can add by annotation or so in the future