Free Camel K from runtime dependency

[squakez]

The goal of this PR is to collect early feedback. Ideally this one should be one of the first PR for Camel K 2.0 branch. It addresses the requirements expressed in #3831. The first goal is to make this mostly compatible with the design and the process in 1.x. We could even include it in any 1.x if we decide to. The main goal is to decouple the strong dependency we have from Camel K Runtime and the Mandrel container image which is required to build a Quarkus native application.

With this PR we're making a CamelCatalog a dynamic CR which is in charge to build its own builder image with the required tools that will be eventually used in the pod strategy build. With this PR we'll be basically free to start our own release cadence, as Camel K should be able to run any Camel K Runtime. The only drawback is that we are forcing any Native build to be run in a pod strategy (which could even seen as a benefit, and maybe in the future as the default strategy to build).

I've decomposed it in a series of commits which hopefully makes the PR easier to review.

With 48f902c I am introducing the possibility to enable a pod strategy in the Builder trait. With this, the user can decide to spin off a build pod strategy without requiring to edit the IntegrationPlatform.
With 98ca5f5 we force any Quarkus Native build to spin off a build strategy pod. This is required as the tools required by a native build are going to be moved off the operator container and included in a dynamic container builder image.
With a94f704 7e74090 and 4a8c805 I've removed the dependency from Maven favoring instead the presence of the Maven wrapper.
With b65a3b9 I'm introducing the concept of a builder image which is an image containing the tools required by a given catalog in order to run its build duties. This image is created on the fly on Camel Catalog reconcilation, which I introduced in 74570b0

Closes #3831

Release Note

feat: Free Camel K from runtime dependency

[squakez]

cc @lburgazzoli @astefanutti @essobedo @claudio4j @oscerd

[claudio4j]

Good job Pasquale +1

Later we can investigate if it's possible to allow multiple builds in parallel

[squakez]

The last commit add a storage capability to the operator. Now we are using a PVC (details to be polished) in order to store the artifacts and being able to reuse among the concurrent builds.

I've run a few test in a local container (minikube) to verify the concurrent access from a certain number of builders (between 5 and 10) and the result was pretty good. It is clear that, the more the concurrent builds, the slower is the time to complete a build, because it seems there is some kind of locking mechanism in order to prevent any conflict on same file resource. However, this one should be mitigated by #592 where we should provide a building order dependending on the possibility to reuse the same kit.

With this change, we default the Pod building strategy, although we should be able to keep using the Routine. I'm going to work on some E2E test to cover the different scenarios.

[squakez]

Latest commits are enabling the possibility for the user to assist the creation of a storage adding the following installation flags:

      --storage-access-mode string                  Persistent Volume Access Mode (any of ReadWriteOnce, ReadOnlyMany, ReadWriteMany or ReadWriteOncePod) (default "ReadWriteOnce")
      --storage-capacity string                     How much capacity to use (default "20Gi")
      --storage-class-name string                   Use a storage class name to create a dynamic volume (if empty will look up for cluster default)

We leverage k8s dynamic provisioning and if no value is provided, we use the default StorageClass.

[claudio4j]

Hi Pasquale, overall I run various integrations concurrently in minikube and it seems fine, good job.