chore(kamelets): embed kamelet repository and remove lookup from gith…

[nicolaferraro]

…ub strategy

This automatically syncs kamelets from the catalog into the operator, without relying on github APIs.

I've added a guard to prevent us releasing a non-tagged revision of the catalog during release.

Release Note

The Kamelet catalog is automatically installed on Kubernetes to let other platforms use it

[lburgazzoli]

I think it is ok as long as the number of kamelet is low but as long term strategy I'd advocate for copy the kamelet to the container image and use a local kamelet repository (we then need to add an option to the operator and the kamel cli to point to that location so it would work also for local run)

[heiko-braun]

How about shipping the kameletes in a separate image, rather than embedded in the operator? It would help if the Kameletes could be updated without touching the operator image. Food for thought.

[nicolaferraro]

I think it is ok as long as the number of kamelet is low but as long term strategy I'd advocate for copy the kamelet to the container image and use a local kamelet repository (we then need to add an option to the operator and the kamel cli to point to that location so it would work also for local run)

I'm in favor of this solution for the short term, bundling the kamelets in the binary is useful to implement kamel local bind, but we agreed on making the CLI lighter and "version independent" in the future, so embedding kamelets goes against this. The local bind can be still implemented and require setting the repo location in advance.

For the long run, an external image may be the solution. It can be shipped directly as release artifact of https://github.com/apache/camel-kamelets. But decoupling kamelet catalog version from operator version require more thinking, especially from an operational point of view.