Add "Components Section" to "Create MCP" Dialog

[In-Ko]

Description
A component selection should be added to the initial version of the "Create MCP" Dialog.

Please refer to the parent item (user-story) of this task for more details and a screenshot.

The component version selection should allow users to enable various components and providers. Users should have the option to select the version from a dropdown.

Good to know

The possible components and versions are on the onboarding API as resource managedcomponents.core.openmcp.cloud (test with k get managedcomponents.core.openmcp.cloud against the onboarding-api).

UI/UX States for a Component

Activated

• Checkmark if component is activated
• A version must be set, by default select latest

Not activated

• Checkmark, unselected, if component is not activated
• A version is set, by default select latest

Enforced Activated

• Checkmark if component is activated
• A version must be set, by default select latest
• Gray out selected Checkmark, on hover, show Tooltip: "Enabled by default - ask Platform Admin"

UI States:

• Hover follows color, schema from UI5 Webcomponent Tables

Acceptance Criteria

• The dialog should present a list of available components (providers) that users can enable for the MCP.
• Make the UI components reusable so we can future reuse it as edit component.
• Each component has:
  • Name (read from Onboarding API),
  • Versions (read from Onboarding API)
  • Stretch: Logos (optional - not read from Onboarding API),
  • Stretch: Description (not read from Onboarding API),
  • Stretch: Link to docs (not read from Onboarding API)
• Users should be able to select multiple components as needed.
• UI States are considered
• Component apiserver. is always selected, type: GardenerDedicated (params not UI-supported yet). (see: Enforced Activated)
• Stretch Goal: Searchbar (local-only!!) - if max 1d lets do it ;-)

Metadata from Releasechannel

• currently Releasechannel does not provide any more information then componentName and available versions
• suggestion:
  1. Metadata just lies in releasechannel repo and frontend picks it from there (not ideal, authentication madness)
  2. Releasechannel generates a json output which can be then be loaded into the cluster for the frontend to pick up as configmap (recommended)
  3. Releasechannels pushs information using OCM components into OCM registry and crate cluster extends managedcomponents api to provide these information. (ideal, highest effort)

Open Question

• Any validation rules to consider? E.g. Minimum one Component to be installed or something?

[GenosseOtt]

@lucasgoral to understand what HTTP requests are fired under the CLI-hood, add -v=10 to have the Go tool show internal logs etc around the requsts/reponse