Add debug logs tracking validation of ScaledObjects on webhook

[be0x74a]

Add debug logs tracking validation of ScaledObjects on webhook

Checklist

• (N/A) 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
• (N/A) Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• (N/A) A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• (N/A) 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 #

[wozniakjan]

I'm wondering if it's safer just to have a map / slice with function names and avoid getting the function name from a program counter. In my past experience, various go compiler optimizations and inlining have made usage of FuncForPC occasionally a little unstable

• runtime: FuncForPC().Name() returns autogenerated inline func name instead of func name when Func with generics golang/go#52809
• runtime: mid-stack inlining vs. FuncForPC golang/go#29582

[wozniakjan]

alternatively, if we go forward with FuncForPC, the code should probably check for nil ptr because FuncForPC can return nil, docs. This will future-proof the code a bit in case of go compiler optimizations changing this behavior

[be0x74a]

I'm wondering if it's safer just to have a map / slice with function names and avoid getting the function name from a program counter. In my past experience, various go compiler optimizations and inlining have made usage of FuncForPC occasionally a little unstable

• runtime: FuncForPC().Name() returns autogenerated inline func name instead of func name when Func with generics golang/go#52809
• runtime: mid-stack inlining vs. FuncForPC golang/go#29582

Ah okay, wasn't aware of it. Since the lookup is being made only during the scope of one function, maybe it's better to follow your suggestion and create a map with the name + function which will be iterated on

[wozniakjan]

lgtm, thank you!

[wozniakjan]

/run-e2e internals
Update: You can check the progress here

[wozniakjan]

just for the record, I think the linter errors relate to a known buggy implementation of the webhooks - #5962

apis/keda/v1alpha1/scaledobject_webhook.go:183:74: verifyReplicaCount - result 0 (error) is always nil (unparam)
func verifyReplicaCount(incomingSo *ScaledObject, action string, _ bool) error {
                                                                         ^
apis/keda/v1alpha1/scaledobject_webhook.go:192:70: verifyFallback - result 0 (error) is always nil (unparam)
func verifyFallback(incomingSo *ScaledObject, action string, _ bool) error {

imho it is not responsibility of this PR to address and fix those