feat(api): Return tipPhysicallyAttachedError from dropTip and dropTipInPlace commands

[SyntaxColoring]

Overview

Half of EXEC-764.

Test Plan and Hands on Testing

I've done this:

1. Run a dropTip command on a robot. Immediately after the pipette drops the tip, physically hold the tip sensor up, to induce a tipPhysicallyAttachedError.
2. Confirm that the robot enters error recovery mode. Confirm with manual HTTP requests that the error shape looks correct.

Changelog

This is the main part of EXEC-764. It adds try/except blocks in the implementations of dropTip and dropTipInPlace commands to turn it into a recoverable, defined error when the sensor detects that the tip is still attached.

This unfortunately does not totally close EXEC-764 because there is a problem with opentrons.hardware's tip tracking getting out of sync with opentrons.protocol_engine's tip tracking. If you retry the command, the robot will incorrectly act as if there is not a tip on the pipette, and slam the tip into the bottom of the tip rack. This is the same problem that we had with pickUpTip's tipPhysicallyMissingError, and we solved it there by adding new hardware API methods that put tip tracking more in control of the caller. I'll do the same thing for these commands in a separate PR.

Review requests

• Does the plan above to fix tip tracking sound good?
• I am not catching stalls or collisions here because that smells like something that we'll want to keep a distinct errorType, but I haven't really thought it through. Any thoughts?

Risk assessment

Low.

[sfoster1]

This looks good to me, and I agree with keeping stalls separate.