Shared data: add `metadata.format` and other metadata fields to labware defs; use in API/PD/RunApp

[IanLondon]

All of Python API, Run App, and PD need to know if a given labware is a tiprack. Right now they're inferring it from labware type (to the effect of is_tiprack = 'tiprack' in 'tiprack-200ul')

This is hacky. Instead, we should have a flag in labware definitions that tells us if a labware is a tiprack or not.

Also, PD would benefit from a general displayCategory metadata field in order to sort labware by category. If we don't put this field in the definitions, PD will have to keep its own external labware type: category data to display labware by category.

It seems like a nice metadata to have for any consumers of our labware definitions to have.

Acceptance criteria

Labware Definitions

FINISHED :heavy_check_mark:

• format metadata field: REQUIRED. A string enum: '96-standard' | '384-standard' | 'trough' | 'irregular'
• displayCategory metadata field, for all labware that can be added to the deck in PD (TBD, see Pantea's spreadsheet of categories) - added in #1752
• deprecated metadata field, indicating a labware isn't going to be supported in the next major release (and PD won't allow users to any deprecated of these labwares)
• isTiprack metadata field: boolean. If field missing, value interpreted to be false. Indicates labware should be treated as a tiprack
• tipVolume: positive number. Volume, in microliters, of the tips of this tiprack.
• isValidSource metadata field, boolean. If field missing, value interpreted to be true. Indicates it's OK to aspirate liquids from the labware (ie a trash or tiprack would not be a valid source)

TODO: :pencil2:

• displayName metadata field, for all labware

Protocol Designer

PD should look in shared-data/definitions and check metadata.isTiprack to determine tiprack or not.

1. Tiprack inference in protocol-designer/src/file-data/selectors/commands.js - getInitialRobotState reducer. This is to populate the initial tip state of all tiprack labware for tip tracking.
2. Tiprack inference in protocol-designer/src/labware-ingred/reducers/index.js - labwareOptions reducer. This is to remove tipracks from the Labware selection dropdowns.

---

TODO: split this out into its own ticket

Python API

• Python API uses tiprack flag in api/opentrons/robot/robot.py - calibrate_container_with_instrument fn (if 'tiprack' in container.get_type():). Instead of looking for the tiprack substring, it should use the new metadata.isTiprack field.
• backwards compatibility: existing behavior should be preserved when no isTiprack field exists in metadata (TODO is this still a concern?)
• Trough is calibrated differently -- should use format == trough instead of current behavior

Run App

• Run App should look in shared-data to determine the isTiprack boolean.

[mcous]

Run App should NOT look in shared-data to determine the isTiprack boolean. It should get isTiprack from the Python server.

I agree that API should tend to be the source of truth for these sorts of things, but given that the app already leans heavily on shared-data for pipettes, until the API is the source of all truth about pipettes, I'm fine to use shared-data for labware, too.

• Will we be versioning our individual labware defs?
• App doesn't need isTiprack; catagory === tiprack is better
  • Other categories that could be useful: plate, trough, tuberack
• For Python protocols, app can look in shared-data. It already does so for pipettes
• For JSON protocols, app can get labware category from the protocol

[IanLondon]

@mcous I talked to @btmorr about this late Friday & he's planning to stop keeping user's shared-data in the CD card & instead put it in the wheel so it's tied to each version. So Run App could safely use shared-data as long as it's the same version as the app.

(Related: we don't need separate JSON files for custom labware because instead they can be defined in either the .py's or the .json protocols, which aids reproducibility.)

For JSON protocols, app can get labware category from the protocol

Right now the labware "type" eg trough-12row is all that is supplied in JSON protocols (along with nickname & slot), so presently JSON protocols rely on their interpreter having synchronized labware definitions. Makes sense to include other data too, though, as you suggest. Maybe all of it?

[mcous]

@IanLondon this ticket looks to be closed based on its acceptance criteria. Please re-open if I'm mistaken!