refactor(app): Support "resume from recovery assuming false positive" action

[mjhuff]

Closes EXEC-791

Overview

See #16556 and the linked ticket for details concerning the reasoning for implementing these changes.

When skipping a step in Error Recovery, the FE essentially calls two commands: handleIgnoringErrorKind, which deals with updating the recovery policy, and skipFailedCommand, which does the skipping. By using isAssumeFalsePositiveResumeKind, we can conditionally determine which policy ifMatch criteria to use, and we can determine which error recovery resume kind to dispatch to the server.

Test Plan and Hands on Testing

• Smoke tested "Tip not detected" error flows. Note that feat(api): Allow treating errors as false-positives (ignore them and continue with the run) #16556 will test this PR alongside it, and that PR is required to test this one.

Review requests

• The new model for determining policy and resume type actions is now predicated on the errorKind as utilized in isAssumeFalsePositiveResumeKind. See the linked ticket, which leads me to think this line of thinking is true. This assumption gets us through 8.2, but is it reasonably sufficient going forward? I think it is, but curious if anyone else has thoughts.

Risk assessment

mediumish. This effectively impacts every route in some way, but it should only directly change the behavior of tip handling error flows.

[sfoster1]

lgtm!

[mjhuff]

Will merge after #16556 merges

[SyntaxColoring]

• The new model for determining policy and resume type actions is now predicated on the errorKind as utilized in isAssumeFalsePositiveResumeKind. See the linked ticket, which leads me to think this line of thinking is true. This assumption gets us through 8.2, but is it reasonably sufficient going forward? I think it is, but curious if anyone else has thoughts.

How does this handle the case where:

1. A pickUpTip command fails
2. You enter error recovery mode
3. You select "Retry picking up tip"

We want the client to POST a retrying fixit command and then POST resume-from-recovery, but from skimming the code, it seems like the errorKind predicate will make it POST resume-from-recovery-assuming-false-positive instead?

[mjhuff]

How does this handle the case where...

All of the retry flows currently utilize retryFailedCommand, sometimes followed by a resumeRun, which always issues resumeRunFromRecovery unconditionally. While the handleIgnoringErrorKind is wired up to resumeRun, there's currently no "ignore error and retry step" path - this existed at one point in earlier iterations of ER but effectively never occurs currently, so we are covered here.

If it's helpful, we can test your specific flow to confirm this is true in practice before merging!

EDIT: Ran the above sequence of steps, can confirm we are issuing resume-from-recovery.

[SyntaxColoring]

Tested and all is well!