Add KEDA Kafka consumer-lag scaling (scale.keda)

[aliok]

What

Part 2 of splitting the original KEDA Kafka scaling work (#4051) into reviewable
pieces. This adds the scale.keda surface — KEDA scaler types and triggers —
and the KEDA deployer implementation for Kafka consumer-lag scaling.

• Add KEDA Kafka consumer-lag scaling support #4051 (closed) — original combined PR, split for reviewability.
• Add top-level scale field to func.yaml #4063 (merged) — Part 1: top-level scale field with scale.min/max and
  scale.kpa plus migration. This PR stacks on that and is now rebased directly
  onto main.

Changes

• Data model — ScaleOptions.KEDA (KEDAScaleOptions + KEDATrigger):
  pollingInterval, cooldownPeriod, and triggers (type http/kafka, with
  targetValue, lagThreshold, activationLagThreshold).
• Validation — scale.keda/scale.kpa are mutually exclusive; scale.keda
  requires deployer: keda and scale.kpa requires deployer: knative. Kafka
  triggers require a run.kafka config. Bounds-checked numeric fields.
• KEDA deployer (pkg/keda/kafka_scaling.go) — builds the ScaledObject and,
  when SASL/TLS is configured, a TriggerAuthentication, both owner-referenced to
  the Deployment so they are garbage-collected on delete.
• describer / lister / remover — corroborate readiness/URL via the Deployment
  when no HTTPScaledObject is present (kafka scaler case).
• Observed state + refuse gate — the provisioned scaler type is recorded as
  observed state (f.Deploy.ScalerType), mirroring the existing Deployer/Expose
  pattern (written back only on a successful deploy, cleared only on a successful
  remove).
• Schema + docs regenerated.

Design decision: refuse in-place scaler/trigger-type switches

Unlike #4051, this PR refuses switching the deployer, scaler type, or trigger
type (http↔kafka) on an already-deployed function — the user must func delete
first. Switching in place could orphan a second scaler on the same Deployment while
Deploy reports success (owner-ref GC can't reclaim it because the Deployment
survives). Same-type parameter tweaks (lagThreshold, topic, consumerGroup,
pollingInterval, …) still update the existing ScaledObject in place — no delete
required.

Behavior tightening

run.kafka.sasl.mechanism is now required when SASL is configured (previously an
empty mechanism was silently accepted). Flagging explicitly for reviewers.

Related issue

• k8s deployer: WaitForDeploymentAvailable errors on a 0-replica Deployment (keda scale-to-zero redeploy) #4068 — WaitForDeploymentAvailable errors on a 0-replica Deployment (keda
  scale-to-zero redeploy race). Reasoned from code, repro TBD; deliberately out of
  scope here to keep this PR focused on the scale.keda surface. Filed separately
  with a suggested fix.

Testing

• Unit tests for the validation surface, the KEDA deployer preflights, the refuse
  gate (ValidateScalerSwitch truth table + Client.Deploy refuse/allow cases), and
  observed-state integrity on remove failure.
• Integration test (//go:build integration) that deploys a Kafka-only function and
  asserts the ScaledObject + TriggerAuthentication are created.
• go build, go vet, and unit tests for pkg/functions, pkg/keda,
  pkg/deployers pass.

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aliok
Once this PR has been reviewed and has the lgtm label, please assign matejvasek for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment