[Feature Request] Permit the removal + change of adjacent deprecated patches

[Sushisource]

Is your feature request related to a problem? Please describe.

User had 2 consecutive patches in history deprecatePatch('patch-1') followed by patched('patch-2') and deployed a change removing the first deprecated patch while deprecating patch-2 and tripped the check in Core that verifies that a patch ID doesn't change during replay.

Describe the solution you'd like

Ideally, it should be possible to make this change. A couple options:

• When it comes to nondeterminism checking specifically for deprecated patches, if there is a patch-id conflict, assume that this was because of the removal of a previously-adjacent deprecated patch, and allow it.
• Allow patches to be emitted / applied in any order. This is generally safe (since we perform lookahead anyway, and activated patches are sent in a batch for a given WFT), but a more invasive change.

[rupalivohra]

We'd really appreciate this fix being made so we can safely remove outdated deprecatePatch calls! We're holding off on doing so for now since one that we did led us to tons of nondeterministic workflows that we ended up needing to terminate. Alternatively, if there's an intermediate fix that allows us to work around the nondeterminism errors/somehow recover our workflows from a failure state, that'd be much appreciated.

[Sushisource]

@rupalivohra For now you should be able to do this as long as you only change one patch at a time. I believe (I haven't had time to confirm this with tests yet though) that this problem only arises if you make simultaneous changes to two adjacent patches.

Though the definition of simultaneous here is a bit confusing - the change to the "second" patch call can't be made until after the workflow has progressed enough that some other command was produced and recorded in history after the removal of the deprecated patch.

[rupalivohra]

this problem only arises if you make simultaneous changes to two adjacent patches.

Unfortunately it's difficult to guarantee that there aren't two deprecatePatch() calls in all cases, and safer to simply not delete the code given that there's no recovery from the bad state.