Fallback to HPA, when KEDA fails.

[ramantehlan]

Bug Description

User passes AutoScaler in ElastiService CRD, which can either be HPA or KEDA.

If it's KEDA, and Elasti Controller isn't able to reach it for following reasons, but not limited to:

• KEDA config given in ElastiSerivce CRD is incorrect.
• KEDA instance is failing for its own internal bug.
• KEDA isn't installed at all, and user copied the default values.

Then Elasti Controller should fallback to HPA for autoscaling the Target.

| This is critical when the Target is receiving traffic, so target needs to be scaled ASAP.

Steps to Reproduce

1. Install Elasti, create CRD for a target service.
2. Scale down the target service.
3. Scale down the KEDA deployment to represent that KEDA isn't accessible.
4. Send traffic to target, then you will see Elasti isn't scaling Target.

Expected Behaviour

When traffic comes, elasti should scale up target ASAP.

Environment

• Kubernetes version: v1.33.1
• Elasti version: Latest
• Installation method (helm/manual): Helm, locally when running E2E test.
• External components in the request path (ingress, service mesh, etc.): Istio, KEDA, same as E2E setup.
• Autoscaler used (HPA/Keda): KEDA
• Cloud provider (if applicable): NO

Additional Context

Add any other context about the problem here (logs, screenshots, etc.)