Spike: Feature gates

[mflendrich]

Spin-off from #1089

#1089 ended up being about a specific type of feature gating: enabling and disabling individual controllers.

This spike is (as a follow up to KEP5) to reach a decision whether (and how) we want to:

• implement an analog to upstream feature gates in the KIC such as to:
  • make all user-facing Kubernetes APIs optional (this is covered by KIC 2.0 - Making all user-facing Kubernetes APIs optional #1089), and to
  • improve communication with our end-users and community on the maturity and longevity of the APIs functionality we maintain going forward.

[mflendrich]

I'd like to ask that we carefully consider:

• the use cases for which we need feature gating,
• the alternative of using the IngressClass parameters field as a potentially more suitable alternative to feature gating (see Service-upstream default controlled by IngressClass parameters #1131)

I'm concerned that general-purpose feature gates are a significant maintenance burden that needs to be well justified, and that possibly "YAGNI".

[shaneutt]

Feature gates are now used by KIC and the documentation lives at FEATURE_GATES.md