[FLINK-40092] Finalize BlueGreen transition after deleting previous deployment

[fqshopify]

What is the purpose of the change

This pull request removes an unnecessary extra reconciliation loop during FlinkBlueGreenDeployment cutover, and in doing so closes a window that could cause a spurious abort with no rollback target.

Previously, after the operator successfully deleted the previous (Blue) FlinkDeployment, it returned noUpdate().rescheduleAfter(RETRY_DELAY_MS) without finalizing, leaving the BlueGreen resource in TRANSITIONING_TO_GREEN. Finalization to the terminal ACTIVE_GREEN state only happened on a later reconciliation.

That extra loop is not just wasteful, it re-runs monitorTransition on Green while the transition is still considered in-flight, so if Green is observed not ready in that window it is routed to shouldWeAbort and Green is suspended. With Blue already deleted, there is no rollback target left so the terminal state is no pipelines running i.e. downtime!

As a result, once the previous deployment has been successfully deleted, the transition can and should be committed forward immediately. This change reuses the existing finalizeBlueGreenDeployment logic in the same reconciliation that deletes Blue, so the abort path is no longer reachable after cutover.

Brief change log

• Pass the target FlinkBlueGreenDeploymentState into deleteDeployment.
• Finalize the BlueGreen transition immediately after successful deletion of the previous FlinkDeployment.
• Preserve the existing retry behavior when deletion fails or is not acknowledged.
• Add a regression test verifying that the transition commits to ACTIVE_GREEN in the same reconciliation that deletes Blue.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changes to the CustomResourceDescriptors: no
• Core observer or reconciler logic that is regularly executed: yes

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

[drossos]

Great fix for the BG bug we found.

CC: @gyfora & @schongloo for 👀 and FYI

[Dennis-Mircea]

Nice change, and it's more than the description says: finalizing in the same reconcile that deletes Blue doesn't just save a loop, it closes a real correctness window. In the old flow, after Blue was deleted the transition stayed in TRANSITIONING_TO_GREEN with abortTimestamp set, so a later reconcile that saw a not-ready Green blip past the abort deadline would abortDeployment and roll back to an already-deleted Blue.