Migrate KEDA HTTP scaling from HTTPScaledObject to ScaledObject with external trigger

[aliok]

Problem

Currently, the KEDA deployer uses HTTPScaledObject for HTTP-based autoscaling. This creates an internal ScaledObject under the hood, which means we cannot create a second ScaledObject for the same Deployment (e.g. for Kafka consumer-lag scaling). KEDA's admission webhook rejects it:

admission webhook "vscaledobject.kb.io" denied the request: the workload 'my-func'
of type 'apps/v1.Deployment' is already managed by the ScaledObject 'my-func'

This makes it impossible to combine HTTP + Kafka triggers on the same function.

Proposed solution

Replace HTTPScaledObject with a single ScaledObject that uses the KEDA HTTP add-on's external scaler as one of its triggers, alongside any other triggers (Kafka, cron, etc.).

The HTTP add-on exposes an external scaler gRPC endpoint that a regular ScaledObject can reference via an external trigger. The interceptor routing can be handled via InterceptorRoute (or the HTTP add-on's route CRD) instead of relying on HTTPScaledObject to set it up.

This would:

1. Allow combining HTTP + Kafka (or any other) triggers in a single ScaledObject
2. Give us direct control over all trigger configuration in one place
3. Remove the hidden internal ScaledObject that HTTPScaledObject creates

Current workaround

Users must choose either HTTP-only or Kafka-only triggers — they cannot be combined.

References

• KEDA HTTP add-on external scaler: the add-on runs a gRPC external scaler service
• KEDA limitation: one ScaledObject per workload