fix(app): make cal commands chain instead of race

[b-cooper]

Overview

In order to avoid various race conditions created by sequential commands being requested of the
robot during/before/after calibration sessions, create mechanism to ensure that they are dispatched
sequentially. Also ensure that wizard only closes on successful deletion, to avoid orphaned session.

Closes #6535

NOTE: these changes have been made within the generic CalibrationPanels component directory, which is only being used in the pipette offset calibration flow. The deck calibration and tip length calibration flows will be refactored to use the panels from this shared directory in a following PR.

TODO: unit tests for new useDispatchApiRequests hook, ensure unit tests for PipetteOffsetCalibrationControl cover new additions

Changelog

• add a new utility hook called useDispatchApiRequests that is very similar to the existing useDispatchApiRequest, but accepts any number of api request actions and will only dispatch each sequential action once the request from the previous action has resolved (status !== PENDING).
• plug this new hook into the pipette offset calibration flow for all sequential calls
• remove temporary setTimeout fix for sequential calls
• while hoisting dispatch machinery up to the PipetteOffsetCalibrationControl component, let it manage closing the wizard so as to avoid orphaned (undeleted) sessions on the robot that can't be viewed or "redeleted" on the app.

Review requests

• run through the existing pipette offset calibration flow and ensure that all transitions occur as expected.

Risk assessment

low, this change is contained within the unreleased pipette offset calibration flow, though this functionality will be added to the other cal overhaul front-ends immediately following this PR merging.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (edge@1b6f3a6). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             edge    #6561   +/-   ##
=======================================
  Coverage        ?   80.23%           
=======================================
  Files           ?      236           
  Lines           ?    20492           
  Branches        ?        0           
=======================================
  Hits            ?    16442           
  Misses          ?     4050           
  Partials        ?        0           

Impacted Files	Coverage Δ
opentrons/config/reset.py	86.95% <0.00%> (ø)
...t_server/service/legacy/models/deck_calibration.py	100.00% <0.00%> (ø)
opentrons/hardware_control/modules/thermocycler.py	94.15% <0.00%> (ø)
opentrons/calibration_storage/get.py	92.75% <0.00%> (ø)
robot-server/robot_server/service/access/router.py	73.33% <0.00%> (ø)
...ot-server/robot_server/robot/calibration/errors.py	100.00% <0.00%> (ø)
...rver/service/session/session_types/base_session.py	91.11% <0.00%> (ø)
...rver/service/session/session_types/null_session.py	95.23% <0.00%> (ø)
opentrons/protocols/execution/json_dispatchers.py	85.71% <0.00%> (ø)
opentrons/hardware_control/modules/mod_abc.py	77.52% <0.00%> (ø)
... and 226 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1b6f3a6...e80c5dc. Read the comment docs.

[sfoster1]

Looks like some typos in the example for the new selector

[sfoster1]

A quick test on my robot does indicate that these requests are chaining!

[Laura-Danielle]

lgtm, also cool