enhancement: add feature gate support

[rexagod]

Allow APIs to be gated conditionally.

Feature gates can be enforced by default, or overridden by the user. The latter takes priority if both cases conflict. Feature gates can be enabled, or disabled, and thus have two custom states. Note that the default state for a feature gate is nil, allowing us to distinguish if a feature gate is levied, raised, or not set.

Signed-off-by: Pranshu Srivastava [email protected]

[rexagod]

For cases such as #1945 (comment).

[rexagod]

cc @SuperQ @discordianfish

Happy to answer any questions around this.

[SuperQ]

I'm not sure we really need this. We've handled feature transitions with simple boolean flags.

[rexagod]

Right, boolean flags surely are a possible solution. However, my inclination towards replacing them with feature gates was motivated by a couple of observations.

• The feature-gates model implemented here assures a proof of trust can be established between the users and the features using version specifications.
• Instead of adding deprecation notice to boolean flags' help texts, we'd have a timeline for every feature right from their inception, allowing users to forethink their dependency on gated APIs. Extending version commitments is also possible.
• All feature-gates will be accumulated in a single document (and auto-updated), making it easier for the user to keep track of all additions.

[rexagod]

That being said, if you think we are better off without these, PLMK and I'll close this.

[rexagod]

@SuperQ @discordianfish I'd be happy to add this to the agenda and pitch it in the call next-to-next week if that sounds good (or have an async discussion here if that works).