refactor(shared-data): Split TypedDict-based bindings for labware schemas 2 and 3

[SyntaxColoring]

Overview

Goes towards EXEC-1206. See that ticket for background.

Changelog

Split the opentrons_shared_data.labware.types.LabwareDefinition TypedDict into LabwareDefinition2 and LabwareDefinition3.

Then, audit the consuming code and try to find boundaries between code that needs to handle both schemas vs. code that should limit itself to schema 2:

• opentrons.protocol_api.core.legacy, which handles Python protocols with apiLevel ≤2.13 and JSON protocols with protocol schema ≤5, is limited to labware schema 2 for scope reasons.

  Labware schema 3 entails major changes in the way we represent labware geometry, including moving a labware's origin from the bottom-left to the top-left. Coping with this will involve a good amount of changes just for new apiLevels (EXEC-78), and I doubt we want to spend time duplicating those changes for old apiLevels too.

• opentrons.calibration_storage is limited to labware schema 2 because allowing schema 3 would break users' ability to downgrade, without further changes to calibration_storage. In theory, at least.

• OT-2 calibration (robot_server.robot.calibration and robot_server.sessions) is limited to labware schema 2 because it is built on the two packages above.

All of those restrictions could be lifted in the future, if we have reason to.

Implementing those restrictions, for now, basically means littering the code with assert schemaVersion == 2. In at least some cases, this is not correct. A user can still load a schema 3 labware, and it will only hit one of these asserts later on, causing a confusing internal error. Ideally, we'd prevent the user from loading the schema 3 labware at our API boundaries, before it reaches our innards and hits one of these asserts. Improving this is ticketed as EXEC-1210 and EXEC-1230.

Next steps

To fully close EXEC-1206, will need to do the same thing for our Pydantic-based models (opentrons_shared_data.labware.labware_definition.LabwareDefinition), and that will happen in another PR.

Also EXEC-1210 and EXEC-1230, as described above.

Test Plan and Hands on Testing

• Run some OT-2 calibration sessions and make sure they don't raise any internal AssertionErrors now.

Review requests

• Does everything I described in the changelog sound like a good idea?
• At the code level, do my boundaries between schema-2–specific code and schema-agnostic code seem correct?

Risk assessment

Medium. There's a risk of something like this happening:

1. For OT-2 calibration, some piece of code loads the latest version of a tip rack.
2. The latest version of the tip rack happens to be defined in schema 3 now.
3. The schema 3 definition makes its way through our code, eventually hits one of these new asserts, and causes a confusing error.

I have not found anything that does that, specifically—it seems like labware loads generally default to the first version, not the latest version—but that gives you an idea of what can go wrong with this.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.63%. Comparing base (f5cdb6b) to head (aafa5a3).
Report is 10 commits behind head on edge.

Additional details and impacted files

@@             Coverage Diff             @@
##             edge   #17517       +/-   ##
===========================================
+ Coverage   26.17%   63.63%   +37.45%     
===========================================
  Files        2835     2835               
  Lines      217682   217918      +236     
  Branches     9276    18140     +8864     
===========================================
+ Hits        56971   138662    +81691     
+ Misses     160694    79061    -81633     
- Partials       17      195      +178     

Flag	Coverage Δ
protocol-designer	18.85% <ø> (ø)
step-generation	4.34% <ø> (-0.01%)	⬇️

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

Files with missing lines	Coverage Δ
...data/python/opentrons_shared_data/labware/types.py	100.00% <100.00%> (ø)
...ata/python/opentrons_shared_data/protocol/types.py	100.00% <ø> (ø)

... and 1516 files with indirect coverage changes

[TamarZanzouri]

code changes look good! can we add tests for the legacy to make sure they raise on schema 3? or maybe you did and I missed it?

[SyntaxColoring]

can we add tests for the legacy to make sure they raise on schema 3? or maybe you did and I missed it?

We can, and no, they're not in this PR yet.

I would like to consider that part of EXEC-1210 because those tests will fail until EXEC-1210 is complete.

[TamarZanzouri]

Nice job! thank you for explaining!