fix(api): fix run cancellation freezing on legacy core

[sanni-t]

Closes RESC-184, RQA-2273

Overview

Successful cancellation of a protocol run using the legacy core relies on making sure that all OT2 robot movements (and delays) happen inside tasks that can be cancelled when a protocol cancel request comes in. But we seem to have missed a few robot movements which were neither wrapped inside cancellable tasks, nor were checking the execution manager status to make sure the robot is okay to be moved.

This PR aims to fix that by putting all such stray direct calls to smoothie inside cancellable tasks.
Right now I've only fixed the direct calls in ot2api.drop_tip() and tested to confirm it fixes the freezing problem. I will be going through rest of the ot2 api to fix any other calls if they exist.
Update: home_plunger also was not being taskified so fixed that as well.

Test Plan

• Try cancelling a protocol exactly when dropping tip (when plunger moves down) and verify that the cancellation completes and the protocol run finishes.
• Try cancelling protocol when plunger is homing in the following sample protocol and verify that the cancellation completes and the protocol run finishes.
• Sample protocol:

metadata = {"apiLevel": "2.11"}

def run(protocol_context):

	p20racks = [protocol_context.load_labware('opentrons_96_tiprack_20ul', '1')]
	p20 = protocol_context.load_instrument('p20_single_gen2', 'right', tip_racks=p20racks)
        dummy_lw = protocol_context.load_labware('opentrons_96_tiprack_20ul', '2')

	p20.pick_up_tip()
	p20.drop_tip()
        p20.move_to(dummy_lw.wells()[0].center())
        p20.home_plunger()

Changelog

• added the missing decorators to calls to backend:
  • fast homing in drop_tip
  • home_plunger method
• Also updated type annotations for the wait_for_running decorator implementation!
  • changed to using ParamSpecs and removed relevant typeVars
  • removed the overloads because they don't seem necessary but please check my logic on that

Review requests

• I went through all calls for backend movement and made sure they all are called in cancellable tasks but would definitely appreciate another pair of eyes checking. Some calls are actually inside nested tasks which shouldn't cause any problems but please raise any concerns if you have. (One such instance has been existing for a while- taskified _move() is called inside taskified home() )
• Make sure my changes to type annotations are correct.

Risk assessment

Medium. Fixes a bug but also re-arranges a few methods decorated behind wait_for_running. For this reason, we should review and QA this thoroughly

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (1624a04) 68.06% compared to head (995d243) 68.09%.
Report is 24 commits behind head on edge.

Additional details and impacted files

@@            Coverage Diff             @@
##             edge   #14312      +/-   ##
==========================================
+ Coverage   68.06%   68.09%   +0.03%     
==========================================
  Files        1621     2503     +882     
  Lines       54710    71589   +16879     
  Branches     4087     9113    +5026     
==========================================
+ Hits        37238    48750   +11512     
- Misses      16817    20711    +3894     
- Partials      655     2128    +1473     

Flag	Coverage Δ
app	65.61% <ø> (+26.89%)	⬆️
components	48.85% <ø> (ø)
g-code-testing	96.48% <ø> (ø)
labware-library	41.10% <ø> (ø)
protocol-designer	35.30% <ø> (ø)
step-generation	86.90% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
api/src/opentrons/hardware_control/api.py	82.38% <ø> (-0.05%)	⬇️
...rc/opentrons/hardware_control/execution_manager.py	89.55% <ø> (-0.86%)	⬇️

... and 885 files with indirect coverage changes

[sfoster1]

Looks great but we might have to dig deep and make sure we're not causing reentrancy issues.

[sanni-t]

Tested the above protocol with API versions 2.11 & 2.15 and verified that the protocol cancels cleanly when:

• dropping tip
• homing plunger during home_plunger()
• homing plungers during home() (to verify nested task cancellation)

[sfoster1]

This looks good to me!

[sanni-t]

Talked with Seth about this and the conclusion is that we should not because disengaging is a quick and harmless action and we shouldn't wait for running for everything without a good reason.

[rickwierenga]

Import ParamSpec from typing breaks compatibility with Python 3.8 and 3.9: https://docs.python.org/3/library/typing.html#typing.ParamSpec. This means OT is now only compatible with Python 3.10.

Can you import it from typing_extensions on 3.8/9 to restore compatibility? I can make a PR if you want.