feat(api,robot-server): add offsets to analyses

[sfoster1]

Overview

Protocol run records offer a view of all labware offsets that were loaded into a run. Protocol analyses however do not, for some reason. Likely this was because when we run analysis, we don't load offsets from the user's robot (there may not be one, after all, and even if there is we want a more general view) - but the protocol itself may load offsets through the use of set_offset().

The app really wants to know which labware have offsets set through set_offset(); we display UI about them to note that doing LPC for them is pointless. Today, that happens by looking at the labware key of the protocol analysis, and displaying that UI for any labware that have an offset ID set in the analysis.

The thing is, the labware key essentially captures a snapshot of the engine's labware state at the point where the analysis ends. Since offsets are based on the current location of a labware, if the labware was in previous locations that (did or didn't) have an offset and ends the protocol in a position that (doesn't or does) have an offset, then the offset ID being present or absent is meaningless - in general, information in the labware key just isn't generally applicable to its contents throughout the protocol. This leads to many bugs about when labware is displayed in the app as having a hardcoded offset.

Since we actually have the information, let's just... put it in the analysis. This PR adds a labwareOffsets key to analysis records, just like the run records have, that contains the same information as the run records. In the common case of a protocol having no set_offset() calls, the key will be empty, because the client isn't loading in a bunch of offsets; but if the protocol uses set_offset(), the resulting labware offset with its ID, the labware URI to which it applies, and the location (by vector and by dict) to which it applies will be present in the analysis for each offset that was set, including those that are no longer in active use by the time the protocol ends.

Test Plan and Hands on Testing

• Run the analysis CLI on a protocol that uses set_offset() and check that the offset is included
• Put the branch on a robot with pre-existing analyses and check that stored analyses without the key are still rendered (the default is to have an empty list)
• Put the branch on a robot and upload a protocol that uses set_offset; check that the offset is included in the analysis

Changelog

• Add labwareOffsets: List[LabwareOffset] to the analysis CLI results object and the robot server analysis results object
• Add TS types in shared-data that list the new key as optional so it can handle previously-generated analyses

Review requests

• Just whether this is a good idea, I guess? see the risk assessment for more, but this adds data that already exists in the engine state store to the analysis docs without altering it in any way.

Risk assessment

Low on the face of it, maybe medium for altering analysis schemata that apply to stored analyses.

This doesn't actually close the below ticket but it does pertain to it.

Closes EXEC-2418

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 56.28%. Comparing base (f50fca9) to head (e6351b3).
⚠️ Report is 2 commits behind head on chore_release-9.0.0.

Additional details and impacted files

@@                   Coverage Diff                   @@
##           chore_release-9.0.0   #21090      +/-   ##
=======================================================
+ Coverage                55.85%   56.28%   +0.42%     
=======================================================
  Files                     3924     3924              
  Lines                   328690   328698       +8     
  Branches                 48349    48353       +4     
=======================================================
+ Hits                    183603   185011    +1408     
+ Misses                  144870   143468    -1402     
- Partials                   217      219       +2     

Flag	Coverage Δ
app	45.72% <ø> (-0.01%)	⬇️
step-generation	5.74% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 40 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mjhuff]

Yay, thank you!

[SyntaxColoring]

Makes sense to me. Just nitpicks. Thanks!

[SyntaxColoring]

Also watch out for the analysis snapshot tests. Sometimes I see them time out, and they end up as "cancelled" instead of "failed," which is easy to miss.

[github-actions]

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