feat: New ScalingSet CRD to deploy isolated interceptors+scalers

[JorTurFer]

Provide a description of what has been changed

Checklist

• Commits are signed with Developer Certificate of Origin (DCO)
• Changelog has been updated and is aligned with our changelog requirements
• Any necessary documentation is added, such as:
  • README.md
  • The docs/ directory
  • The docs repo

Fixes #241

[wozniakjan]

I like this approach very much, here is a couple of minor nitpicks from the first pass, I will take a deeper look later today

[wozniakjan]

I am sure this is empty only because the PR is still WIP but for discussion sake mentioning controller may want to capture some conditions here, such as:

• unable to create interceptor/scaler
  • kube-api rejects some resource creation
  • failure to form the externalScalerURI
• interceptor/scaler are not running with desired replica count and/or are unhealthy
• possibly getting some basic stats from interceptor admin endpoint?

[zroubalik]

First pass of review

[zroubalik]

We should provide some status about the resource, at least Ready condition

[zroubalik]

We should consider using duck types instead of metav1.Object here, to add some type safety.

[zroubalik]

@wozniakjan has also an idea on this.

[JorTurFer]

WDYM? We do almost the same in KEDA with ScaledObjects and ScaledJobs. Would be enough if I validate the type and return an error if the type isn't correct?

[wozniakjan]

I mentioned to @zroubalik earlier that maybe we could explore type aliasing or trivial type definitions. In this case, both ScalingSets as well as ClusterScalingSets seem to have exactly matching structure so maybe we could do something along the lines of either

type ClusterScalingSet ScalingSet

or

type ClusterScalingSet = ScalingSet

I had used the first one with controller-runtime v1 some eons ago successfully and haven't tried it ever since, but could be a good fit for this usecase unless controller-runtime became more strict regarding types.

The implementation went something like this: https://go.dev/play/p/sxZiO_BDw4z

[JorTurFer]

I didn't know that this works with kubebuilder but I can give a try because yes. both types are exactly the same, just cluster scoped or namespaced

[JorTurFer]

I appreciate your feedback, I'll review it, but don't worry about reviewing the PR for the moment as it's still a WIP and there are a couple of pending stuff, like propagating the status info the the CRD, documentation, more test coverage , etc

You can review it if you want, but there can be multiple changes until the final version :)

[JorTurFer]

I'm removing the changes applied to my local branch

[JorTurFer]

I've been talking about this with @zroubalik and to not lock you with the code refactor, we will agreed with merging this PR as it is (it works actually) and I'll open a followup PR in a few days/weeks (before the release for sure) adding the pending stuff to complete this PR (such as but not exclusive):

• Documentation
• CRD Status propagation
• Autoscaling
• Support for global configurations (timeouts, TLS, watched namespaces, etc...)

[kahirokunn]

This feature is great!
I can't wait to start using it!

[kahirokunn]

@wozniakjan Hello!
Is there anything else you need to do to merge this PR?
If you need help, I'd be happy to help.

[kahirokunn]

I have prepared a helm chart 👍
kedacore/charts#703