feat(api): simulate liquid probe results

[caila-marashaj]

Overview

In implementing liquid probing, we implemented a placeholder for simulating liquid_probe_in_place, where we just return the top position of a well unconditionally. This is fine for testing aspirate, but causes a problem if you want to dispense, or really simulate a realistic chain of liquid handling actions.

This code changes that simulated liquid probe function so that it creates and returns a SimulatedProbeResult object, and passes that into the protocol engine. This object will only be created by pipetting::liquid_probe_in_place, and will keep track of the state of aspirates/dispenses in a given well until another liquid_probe is called on the same well. I think we can eventually use this to do some cool error prevention/handling as it pertains to real liquid probe results from on-robot runs, but for now the running state will just be updated in the same place where well updates like _handle_liquid_probed and _handle_liquid_operated are made.

Changelog

• have VirtualPipettingHandler::liquid_probe_in_place create & return a SimulatedProbeResult instead of well depth
• create a LiquidTrackingType that is a Union of float and SimulatedProbeResult
• modify geometry.py functions and places where liquid height/volume values are analyzed to handle SimulatedProbeResults
• create a SimulatedType in update_types

Test Plan

• check that protocols involving both liquid tracking and regular aspirate/dispense pass protocol analysis
• make sure liquid tracking protocols still behave as they do on edge
• make sure non-liquid tracking aspirate/dispense protocols behave as they do on edge
• unit tests

[sfoster1]

Inline changes, but let's also do the following:

The idea for this is that eventually the simulated-value standin will be an instance of a class that can support math operations and return itself; and that new instances will be returned from every unique probe. To support that now, we should make this a class and an instance of that class instead of a string literal. We should define it in opentrons.types, the way other data structures shared by the engine and protocol api, like SlotName, are defined; then we can import it into the engine.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 25.68%. Comparing base (e583471) to head (7be981c).

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #17582   +/-   ##
=======================================
  Coverage   25.68%   25.68%           
=======================================
  Files        2851     2851           
  Lines      219457   219457           
  Branches    17971    17971           
=======================================
  Hits        56363    56363           
  Misses     163079   163079           
  Partials       15       15           

Flag	Coverage Δ
protocol-designer	18.94% <ø> (ø)
step-generation	4.37% <ø> (ø)

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

[sfoster1]

Looks great! Let's maybe use the modern type syntax more though. I'm really excited for this one

[github-actions]

A PR has been opened to address analyses snapshot changes. Please review the changes here: #17653

[github-actions]

A PR has been opened to address analyses snapshot changes. Please review the changes here: #17659

[github-actions]

A PR has been opened to address analyses snapshot changes. Please review the changes here: #17659