A workflow build produced with operator version N+1, re-uses the SonataflowBuild produced with operator version N, when a re-build in operator version N+1 is produced

[wmedvede]

Describe the bug

For example, given an installation with the SonataFlow operator 1.33.0, when it is upgraded to 1.34.0, the following situation is produced:

If we have deployed workflow with the preview profile, that was built, in 1.33.0, when the operator is upgraded too 1.34.0, we have that the workflow will continue running as is.
In a later point in time, if a re-build of the workflow is produced, for whatever reason, we have that the new build is started, this time with the builder image 1.34.0, but, preserving the initial SonataFlowBuild build generated in 1.33.0.

We must analyse if this is bug, or if we need adjustments.

Possible alternatives.

1. since the workflow was generated with 1.33.0, unless the user voluntary deletes, and re-deploy the workflow, potential new re-builds must be produced with the SonataFlowBuild produced in 1.33.0 and the builder image for 1.33.0.

2. when a new re-build of the workflow is produced in 1.34.0, the operator must not only use the builder image 1.34.0 but also re-generate the SonataFlowBuild in 1.34.0 before executing the build.

3. any other alternative. (maybe the SonataFlowBuild shouldn't save the added QUARKUS_EXTENSIONS as part of it.)

Alternatives above must consider that the SonataFlowBuid is keeping the information of the QUARKUS_EXTENSIONS potentially added for a particular build, and here is one point of discussion and where a problem might be introduced. Specially for the automatically added persistence related extensions.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Golang version

No response

Operator-sdk version

No response

SonataFlow Operator version or git rev

No response

Additional information

No response