feat: modify web/workers for keda autoscaling

[yosefmih]

Currently, we have two different autoscaling states

1. Standard HPA based autoscaling
2. Manually configured custom autoscaling via KEDA. We have done this without specifying the HPA name KEDA should create per ScaledObject. KEDA defaults to keda-[hpa].

With the introduction of standard support for KEDA autoscaling, there are three different edge-case transitions we should be able to handle smoothly:

a. Standard HPA -> Standard KEDA

b. Manual KEDA -> Standard KEDA

c. Standard KEDA -> Standard HPA

a and b are edge cases because the KEDA validating webhook blocks creation of a ScaledObject if the target deployment is managed by another HPA. This blocks the progression of the helm upgrade (helm creates the ScaledObject before deleting the old HPA. One way of handling this is specifying an annotation on the ScaledObject to make KEDA just adopt the existing HPA. Unfortunately this fix introduces the edge case c. During a helm upgrade for the transition in c, helm patches the standard HPA and then deletes the ScaledObject. The finalizer for the ScaledObject in turn deletes the HPA, leaving us with no autoscaling.

The patches in this PR handle this by annotating the HPAs with validations.keda.sh/hpa-ownership: "false" which makes the keda validation webhook pass them during the check. This means a and c can happen safely (KEDA will just create/delete a new HPA). b is a limited set of scenarios which we will handle on a case by case basis (we will use enabling the flag as a forcing function to do the check - we can patch the HPA with the necessary annotations).

This PR also adds an annotation on web services to add a porter.prometheus/scrape annotation.