fix(api): Fully stringify well names

[SyntaxColoring]

Overview

Fixes RSS-368.

Test Plan

Run some PAPIv≥2.14 protocols through opentrons_simulate and check the run log. You shouldn't see the string None anywhere. The location strings should match PAPIv≤2.13.

Here's a test case demonstrating how we print a well of a labware on an adapter on a module on a deck slot. It also demonstrates how we prefer to print the user-defined labware label, but if that doesn't exist, we fall back to the display name specified by the labware definition.

from opentrons import protocol_api


requirements = {"robotType": "Flex", "apiLevel": "2.15"}


def run(protocol: protocol_api.ProtocolContext) -> None:
    heater_shaker = protocol.load_module("heaterShakerModuleV1", "D1")
    source = heater_shaker.load_labware(
        "opentrons_96_wellplate_200ul_pcr_full_skirt",
        adapter="opentrons_96_pcr_adapter",
    )
    destination = protocol.load_labware(
        "opentrons_96_wellplate_200ul_pcr_full_skirt", "A2", label="destination"
    )

    tip_rack = protocol.load_labware("opentrons_flex_96_tiprack_50ul", "B1")

    pipette = protocol.load_instrument(
        "flex_1channel_50", mount="right", tip_racks=[tip_rack]
    )

    heater_shaker.close_labware_latch()
    pipette.transfer(50, source.wells()[0], destination.wells()[0])

$ pipenv run opentrons_simulate ~/Desktop/complicated_locations.py
/Users/maxmarrone/.opentrons/robot_settings.json not found. Loading defaults
Belt calibration not found.
Latching labware on Heater-Shaker
Transferring 50.0 from A1 of Opentrons Tough 96 Well Plate 200 µL PCR Full Skirt on Opentrons 96 PCR Adapter on Heater-Shaker Module GEN1 on D1 to A1 of destination on A2
	Picking up tip from A1 of Opentrons Flex 96 Tip Rack 50 µL on B1
	Aspirating 50.0 uL from A1 of Opentrons Tough 96 Well Plate 200 µL PCR Full Skirt on Opentrons 96 PCR Adapter on Heater-Shaker Module GEN1 on D1 at 8.0 uL/sec
	Dispensing 50.0 uL into A1 of destination on A2 at 8.0 uL/sec
	Dropping tip into A1 of Opentrons Fixed Trash on A3

Details

This fixes two problems with how PAPIv≥2.14 was stringifying well names when they were printed to the opentrons_simulate run log:

1. We were only printing the user-specified labware label. That's it. If the user didn't specify a labware label, we were printing None, without making an attempt to fall back to the display name specified by the labware definition.
2. We were just printing the name of the labware itself, without descending down to the labware's parents. So, the name of the module or deck slot that the labware was on wouldn't get printed.

We fix both of these by adding a helper function to opentrons.protocol_api.core.engine that queries the ProtocolEngine for full location information and builds a human-readable string out of it. It works recursively, so it supports deep locations like "well A1 of labware Foo on adapter Bar on module Baz on C2."

This brings PAPIv≥2.14's user-facing behavior in line with that of PAPIv≤2.13.

For comparison, PAPIv≤2.13 accomplished this through a combination of this helper function, and computing the human-readable strings eagerly as Well objects were constructed. That approach isn't sufficient for us anymore because labware can move around throughout the protocol.

Review requests

Any other stringifications that need to be fixed?

Risk assessment

Low.

[jbleon95]

Curious about if performance is affected by the increased amount of engine client calls, but otherwise looks good outside of my couple suggestions below.

[codecov]

Codecov Report

Merging #13764 (18bb36f) into chore_release-7.0.1 (e8ba506) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@                   Coverage Diff                   @@
##           chore_release-7.0.1   #13764      +/-   ##
=======================================================
- Coverage                71.26%   71.25%   -0.01%     
=======================================================
  Files                     1588     1588              
  Lines                    52761    52744      -17     
  Branches                  3451     3451              
=======================================================
- Hits                     37602    37585      -17     
  Misses                   14624    14624              
  Partials                   535      535              

Flag	Coverage Δ
app	43.57% <ø> (ø)
g-code-testing	96.44% <ø> (ø)
notify-server	89.13% <ø> (ø)

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

see 8 files with indirect coverage changes

[SyntaxColoring]

Curious about if performance is affected by the increased amount of engine client calls

Hm, yeah.

It seems like ideally, we would maybe only compute the parts of the run log that are actually required by the caller. For robot-server, that's basically none of it, whereas for opentrons_simulate, it would include this stuff...

[SyntaxColoring]

Waiting for #13709 to hit chore_release-7.0.1 before we merge this into chore_release-7.0.1.