fix(shared-data): update tipracks to URIs

[sanni-t]

Closes AUTH-1293

Overview

Replaces the tiprack names with URIs in Ethanol & Glycerol definitions

Review requests

Do we want to rename the liquid-class directory to liquid_class? (dash vs underscore)

Risk assessment

None

[ddcc4]

Shrug ... What's the difference between the old tiprack names and the new URIs? (I.e., when would we use one vs the other?)

[SyntaxColoring]

Makes sense, thanks.

No opinion about hyphens vs. underscores. I don't think underscores are typical in JS, so it'll break somebody's convention no matter what we do.

[ddcc4]

No opinion about hyphens vs. underscores. I don't think underscores are typical in JS, so it'll break somebody's convention no matter what we do.

I think the existing filename doesn't have enough types of word separators:

shared-data/liquid-class/definitions/1/ethanol_80.json
                  ^                           ^
                hyphen                    underscore

Compare that to a more sophisticated filename like this, which shows off our word separator capabilities much better:

shared-data/pipette/definitions/2/liquid/eight_channel/p50/lowVolumeDefault/3_0.json
      ^                                       ^               ^
    hyphen                                underscore       camelcase

or the masterpiece

analyses-snapshot-testing/tests/__snapshots__/analyses_snapshot_test/test_analysis_snapshot[ac886d7768][Flex_S_v2_15_P1000_96_GRIP_HS_MB_TC_TM_IDTXgen96Part1to3].json

😝😝😝

[sanni-t]

Shrug ... What's the difference between the old tiprack names and the new URIs? (I.e., when would we use one vs the other?)

The URIs are the full paths to the definition file of the tiprack. So it's inherently versioned and refer to a very specific instance of a labware definition. The names are not versioned. For the purposes of attaching any specific properties and behavior to a specific tiprack (or any labware if speaking in general terms), it's usually better to use the URIs to categorize instead of names so that if your labware's definition (& hence version) changes, you don't break any existing liquid class behavior. It also allows you to distinguish between an in-built opentrons labware and a same-named custom labware created by the user.