[9.99.x-prod][SRVLOGIC-221] Pod instances keep spawning and terminating when deploying the workflow

[wmedvede]

Jira: https://issues.redhat.com/browse/SRVLOGIC-221

Description of the change:

Motivation for the change:

Checklist

• Add or Modify a unit test for your change
• Have you verified that tall the tests are passing?

How to backport a pull request to a different branch?

In order to automatically create a backporting pull request please add one or more labels having the following format backport-<branch-name>, where <branch-name> is the name of the branch where the pull request must be backported to (e.g., backport-7.67.x to backport the original PR to the 7.67.x branch).

NOTE: backporting is an action aiming to move a change (usually a commit) from a branch (usually the main one) to another one, which is generally referring to a still maintained release branch. Keeping it simple: it is about to move a specific change or a set of them from one branch to another.

Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.

If something goes wrong, the author will be notified and at this point a manual backporting is needed.

NOTE: this automated backporting is triggered whenever a pull request on main branch is labeled or closed, but both conditions must be satisfied to get the new PR created.

[wmedvede]

This PR goes hand in hand with the upstream one: apache#392

[rgdoliveira]

note: PR to include in a possible CR2 build

[wmedvede]

For the record:

1. I have built this branch locally by restoring the go.work file

2. I have deployed a workflow that calls a rest service with kn deploy, previously creating a SonataFlowPlatform that configures
   the devMode image to "quay.io/kiegroup/kogito-swf-devmode-nightly:latest" to avoid issues trying to get the registry.redhat.io/openshift-serverless-1-tech-preview/logic-swf-devmode-rhel8

3. I can see the workflow running and no spawning pods

4. Since this PR introduces a limited set of changes, only at the operator side code, and also works fine in master, I conclude that this can be merged safely by ignoring the checks as suggested

@rgdoliveira @ricardozanini

[ricardozanini]

@rgdoliveira won't we have this after the syncs? So we could cherry pick it directly from main?

[rgdoliveira]

yeah, but fow now the sync between midstream/main-apache branch and midstream/main branch is done manually by me from time to time as the automation is still under development.

Anyway the cherry-pick would be the same process, like cherry-picking from main in midstream (if the commit was there already) and creating the PR to 9.99.x-prod branch.

Also in this case @wmedvede went ahead and created the PR to midstream before the upstream one is merged - I guess for us to keep track what we want to include in a CR2.

[rgdoliveira]

Merging this one as upstream PR is already merged and we want to include it in CR2