fix: fix isFallbackEnabled when using scaling modifiers

[y-rabie]

Currently, the behavior when using ScalingModifiers is that if any of the triggers has a metric type of AverageValue then fallback is enabled. Intuitively, this is not accurate. When using ScalingModifiers, we should only care about its metricType, no matter what metricSpec is passed to the current call of isFallbackEnabled.

Also, this helps with the fact that currently, doFallback assumes that the metric type when using ScalingModifiers is AverageValue without any kind of checking, which under the current implementation, is not guaranteed to be the case.

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]

nice catch! 🚀
Thanks a lot for the fix 😄

[JorTurFer]

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

[zroubalik]

@y-rabie could you please update the changelog?

[zroubalik]

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