Add a DSL context or metadata endpoint

[kahboom]

Accompanying issue on the frontend: https://github.com/KaotoIO/kaoto-ui/issues/1797

Is your feature request related to a problem? Please describe. We need an endpoint that provides contextual DSL-specific data for the frontend. The motivation for this is to address the following concerns:

1. Not adding more complexity or maintenance to the frontend for DSL-specific functionality
2. Making it easier to start working on bigger DSL-specific features without compromising # 1
3. Not mixing DSL-specific stuff on the frontend (@Delawen)

One example of such a use case is with Beans support (https://github.com/KaotoIO/kaoto-ui/issues/1722).

Describe the solution you'd like One middle ground discussed was to offer an endpoint that provides DSL-specific context:

• Such an endpoint could include things like metadata (beans, for example), DSL-specific terminology for things like the step catalog, and which views to show (more below). We could make this an epic and branch those into smaller issues if preferable (cc @igarashitm).
• To avoid having to add in generic extensions which are stored and maintained externally: We currently pass the frontend a string with an external URL (like we do for step extensions) from the view definition catalog. Instead, we would pass a string with a component name (for example KameletBean or whatever), so the component can live alongside the rest of the Kaoto UI code but only the backend decides when it should be loaded. As far as frontend knows, it's just another component that will be lazily loaded.

Describe alternatives you've considered We have previously addressed similar features using step extensions, however, this abstraction comes at a high cost in terms of development speed and maintainability.

Additional context If in the future we decide to abstract this further then it would be easy to move such components out to another repo or whatever over engineering we decide to do at that point 😀 but at least this would make it much faster to implement DSL-specific features without compromising multi DSL support.

[Delawen]

And why are we adding a specific view definition endpoint for metadata instead of using the current view definition endpoint?

[igarashitm]

Down the road we also need an endpoint to return a list of

• Supported expressions
• Supported dataformats

And those are to be extracted from upstream camel-yaml-dsl schema.

Currently the name of the expressions are hardcoded in

• backend model objects
• step extensions

[igarashitm]

Maybe for the 2nd interation, but together with metadata schema, we can send "templates" - which is a template for the metadata. For example, DataSource bean is very popular and it's properties are very well known. We can bundle a DataSource template together with beans schema so frontend can prefill well known property names.