Tighten plugin feature-flag API

[marckhouzam]

Describe the feature request

With #3665 getting merged soon, we will have decoupled the Feature-Flags from the cli/runtime library and moved them into plugin specific code. The idea is that plugins should specify their feature-flags themselves, and the core CLI will then store them in the config file.

However we should not let plugins define the entire feature-flag path for their flags. It gives them too much control over where flags will be stored. They should only be able to specify a subpath under features.<pluginName>, and it should be the CLI that prepends the fixed features.<pluginName> prefix. Currently, by being able to specify the entire path, a plugin could create or modify feature-flags for other plugins or even for the core CLI.

For example, the feature-flag features.management-cluster.standalone-cluster-mode should only be defined as standalone-cluster-mode by the management-cluster plugin and passed that way to the CLI in the PluginDescriptor. The CLI would then add the features.management-cluster prefix before storing it in the config file.

This came out of this discussion: #3665 (comment)

Describe alternative(s) you've considered

Affected product area (please put an X in all that apply)

• (x) APIs
• ( ) Addons
• ( ) CLI
• ( ) Docs
• ( ) IAM
• ( ) Installation
• (x) Plugin
• ( ) Security
• ( ) Test and Release
• ( ) User Experience
• ( ) Developer Experience

Additional info

Note that the features.global.tkr-version-v1alpha3-beta and features.global.package-based-lcm-beta are "global" feature-flags, but are created by plugins. This is something that would need to be fixed to be able to properly address the current issue.

This issue would benefit in being fixed before the cli-runtime lib or the plugins are split away from Framework so that we could make the change everywhere at once.