Operator restart Integrations on upgrade

[squakez]

Verified when upgrading from Camel version 2.3.0 to 2.3.1. Any existing integration is restarted and even a new Pod is scheduled (see log below). It is very likely because we use the operator version to calculate digest (see #5192) when we really should account for runtime version/provider instead.

NAME   PHASE     RUNTIME PROVIDER   RUNTIME VERSION   KIT                        REPLICAS
# Camel K 2.3.0
test   Building Kit   quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   
test   Deploying      quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   
test   Running        quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   0
test   Running        quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   1
test   Running        quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   1
# Camel K 2.3.1 upgrade
test   Running   quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   1
test   Running   quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   2
test   Running   quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   1
test   Running   quarkus            3.8.1             kit-couff1l2cjmc73fhht0g   1

The rebuild should only be performed manually.

[squakez]

I had a quick look at the history of the project and talking to historical contributors and it seems that I was making confusion between the concept of a build (which trigger a new Build, IntegrationKit, etc...) and the deploy. The original design was done to make sure the operator don't rebuild until the user would trigger the build manually (kamel rebuild), while keeping the possibility to redeploy the Integration according the new operator specifications (ie, changes in the Deployment). To be noticed that the rollout of the new Pod is done in accordance with this principle and it is not even happening every upgrade, but only when the new operator deployment logic make the changes that are transparently applied to the Integration resources involved.

I will take the opportunity and clarify this aspect adding the proper documentation.

In any case, the general review of the upgrade process is something that could be discussed and redesigned in the wider scope of the multi tenancy work effort that is ongoing as it seems to be a key feature that the new model should be able to provide in a seamless way.