feat(api): Allow treating errors as false-positives (ignore them and continue with the run)

[SyntaxColoring]

Overview

This does the interesting part of EXEC-676. See there for background.

Changelog

When a command encounters a defined error, it now enacts two state updates:

1. The first one represents all the changes that the command made up to, and including, the point of failure. This is what defines the semantics of the error. This is what we had before.
2. The second one is new, and represents additional changes to make if a client claims that the error was a false-positive.

For example, if a pickUpTip fails with atipPhysicallyMissing error:

1. A tip is logically consumed from the tip rack, but no tip is logically placed on the pipette. (These are the documented semantics of the tipPhysicallyMissing error.)
2. But if a client says that the error was a false-positive—e.g., the sensor was broken, or it's a dry-run—a tip is logically placed on the pipette.

We unfortunately need to go out of our way to keep the hardware API's state in sync with Protocol Engine's state as we do this.

(All of the above is EXEC-785.)

We can use this to allow continuing fromtipPhysicallyMissing and tipPhysicallyAttached errors in pickUpTip, dropTip, and dropTipInPlace commands. (EXEC-778, EXEC-779.)

This does not quite expose this through robot-server's HTTP API just yet. That's left to other PRs.

Test plan

• Flip the hard-coded resume_from_recovery(reconcile_false_positive=False) to resume_from_recovery(reconcile_false_positive=True). Make sure that a protocol can continue from failed pickUpTip and dropTip commands as if they succeeded. For example, try running a protocol with lots of aspirates and dispenses and interesting path planning, and physically don't place the tip rack, and select Ignore and continue every time an error pops up.
• Edit the hard-coded default error recovery policy to "assume false-positive and continue." It should act as above, except this time you shouldn't need to manually select Ignore and continue each time—it should just do that automatically.

Review requests

• Naming?
• Any thoughts on the fundamental approach?
• I really do not like HardwareStateSynchronizer. Any thoughts on a better approach?
  • Can we "just" delete all of this statefulness from the hardware API?
  • Failing that, what if we emulated hardware statelessness by, e.g., doing hardware_api.cache_tip(current_protocol_engine_tip) before every hardware movement call?

Risk assessment