Document the locked state of feature gates

[tengqm]

This is a Feature Request

What would you like to be added

When a feature gate is about to mature (or deprecate), the Kubernetes core code base will selectively mark it with lockedToDefault: true. This flag means the the gate is still there and you won't risk a "unknown feature gate" error when the gate is explicitly specified, AND more importantly, the gate cannot be set to values other than the default one.

This used to be an implementation details, aka some information only matters to the developers. However, starting from v1.32, feature gates that are marked with lockedToDefault: true is not shown in the --help message from the core components (e.g. kube-apiserver).

We need to faithfully document this details.

• Update the feature gate data files with "locked-to-default" information
• Augment the related shortcode to expose this to docs users

Why is this needed

There are always some features that are seemed very important for users.
Users will struggle with the support levels of a feature, not simply about its Alpha-Beta-GA status, but also when it is okay to be specified as a command line argument (or configuration option), and when it is not okay.
They also need to know when a gate is accepted by a component binary, is it really effective.
Silent failures are sometimes the most dangerous rabbit holes for cluster operators.

Comments

This is gonna be a labor-intensive work.
Clearly articulate the effect of locked is another challenge from documentation's perspective.

[sftim]

/lifecycle frozen

Before we close this issue, we should check if we implemented it. If we didn't, let's clean up any front matter changes that no longer apply.

/area web-development
/triage accepted

And slightly relevant, but let's capture it:
/sig architecture

[sftim]

/priority important-longterm