feat(api, shared-data): Add locatingFeatureAsParent/Child to valid entity types

[mjhuff]

Works toward EXEC-77

Overview

Adds locatingFeaturesAsParent and locatingFeaturesAsChild properties to the various entity types that may be involved in a stackup where relevant. This PR is best viewed commit-by-commit.

Notably, 686e400 adds support for locatingFeaturesAsParent to all addressable areas. It sounds like we have to make this a required property even for the module addressable areas, because we can't rely on a child labware always resting on a parent module-based location. Down the road, this would imply that we will have duplicated locatingFeaturesAsParent data between modules and addressable areas, but I suppose there's no way around this.

Test Plan and Hands on Testing

• Covered by passing CI. There are no functional changes.
• Snapshot failures all seem expected given the PR changes.

Changelog

• Add locating feature properties to module defs, labware defs, addressable areas, and deck slots.

Review requests

• It will make accessing locatingFeatureAsParent much cleaner in our utils if the addressable area property is locatingFeatureAsParent, camel-cased, which is consistent with the camel-cased locatingFeaturesAsParent present in labware defs. However, this does break the current AddressableArea convention of snake-casing properties. Are we ok with this or not?
• Does the above logic concerning requiring all addressable areas to specify a locatingFeatureAsParent seem valid?

Risk assessment

none

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 23.67%. Comparing base (482c6da) to head (9c2cfd6).
Report is 21 commits behind head on edge.

Additional details and impacted files

@@            Coverage Diff             @@
##             edge   #18628      +/-   ##
==========================================
+ Coverage   23.38%   23.67%   +0.29%     
==========================================
  Files        3237     3240       +3     
  Lines      279313   280103     +790     
  Branches    28098    28561     +463     
==========================================
+ Hits        65306    66314    +1008     
+ Misses     213980   213762     -218     
  Partials       27       27              

Flag	Coverage Δ
protocol-designer	19.10% <ø> (+0.04%)	⬆️
step-generation	4.86% <ø> (+0.34%)	⬆️

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

see 32 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.

[sfoster1]

I think it's a good idea to make everything have the feature, yes. I think it is annoying to have to special case code for the underscores but it's worth it to keep the attribute names consistent. I wish the other stuff was snake case too 😢

[sfoster1]

🐍 🐍 🐍 🐍 🐍

[github-actions]

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

[mjhuff]

The underlying problem we now come up against is that loadModule commands contain the module definition which means we have to do database migration...or not: EXEC-212.

After consulting with @SyntaxColoring , the plan is to make locatingFeaturesAsParent as optional for now on for module defs, then do EXEC-212 immediately, and then make this field required again.

[github-actions]

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

[github-actions]

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