refactor(api): Allow cache_tip() to overwrite the current tip

[SyntaxColoring]

Overview

The hardware API has two similar methods, add_tip() and cache_tip(). One of their differences is that if there's already a tip, add_tip() no-ops, whereas cache_tip() raises an AssertionError.

Neither behavior is really appropriate for error recovery. We mostly want Protocol Engine's state to be the single source of truth, and we want to synchronize the hardware API's state to it (if the hardware API must have its own state at all). It's difficult to do that reliably if the hardware API's state-setting methods are context-sensitive like this.

So this changes cache_tip() to idempotently overwrite the hardware API's current tip instead of raising an AssertionError.

Goes towards EXEC-778.

Test Plan and Hands on Testing

• Run a protocol and make sure tip pickups, tip drops, aspirates, etc. keep working as normal.
  • OT-2
    • Can't easily test this right now because of unrelated errors on edge
  • Flex
• Induce a tipPhysicallyMissing error and make sure the "retry failed step" error recovery flow still works.

Changelog

• 1f9bbff: Move cache_tip() next to add_tip(). As long as we have to maintain them both in parallel, this makes that easier. No behavioral change. This highlights some additional subtle differences between the two methods (like set_current_volume()), which I'm not addressing in this PR.

• 0cb1605: The actual behavioral change described in the overview.

• 1bfc529: Get Protocol Engine to uniformly use cache_tip() instead of add_tip().

  This is theoretically a behavioral change, but it should be safe, given the two call sites. HardwareStopper was basically setting the tip to...the current tip, so it's just another flavor of no-op. pick_up_tip() should only ever get to this point after it's validated that there is no tip on the pipette, so the behavioral difference doesn't come into play.

Review requests

Does this seem like a not-wrong hardware API direction?

Risk assessment

Low.

[sfoster1]

Yup, I like this and think it's the right direction to go.