feat(api): implement loadLiquidClass command in PE

[ddcc4]

Overview

This is the second half of AUTH-851.

This implements the loadLiquidClass() command using the liquid class store from the previous PR.

Liquid classes are read-only in the Protocol Engine, so each liquidClassId refers to one specific liquid class definition. Each mutation of a liquid class needs to be stored under a different liquidClassId. The caller can specify the liquidClassId if they want to, or else we will generate one for them.

So there are 4 cases we need to handle:

1. Caller did not specify a liquidClassId and the liquid class is new: Generate a new liquidClassId.
2. Caller did not specify a liquidClassId but the liquid class has already been stored: Reuse the existing liquidClassId.
3. Caller specified a liquidClassId that we haven't seen before: Store the liquid class under the new liquidClassId.
4. Caller specified a liquidClassId that's already been loaded: Check that the incoming liquid class matches the one we previously stored, and:
   1. If the incoming liquid class exactly matches the existing one, do nothing.
   2. If they don't match, raise an error.

Test Plan and Hands on Testing

I added 5 test cases to cover each of the scenarios above.

Review requests

Could someone teach me what StateView.get_summary() is supposed to do?

Risk assessment

Low risk, liquid classes are not released yet and these changes should be dev-only. This change makes the Protocol Engine state marginally larger.

[sanni-t]

Definitely!

Could someone teach me what StateView.get_summary() is supposed to do?

Will answer your question here. StateView.get_summary() returns a snapshot of the state of a selection of the engine components. The selection is determined mostly by client needs (or any entity that starts a run and needs to monitor its progress) as this state summary is a big part of the 'run data'.

Places where run data (and by implication, state summary) is provided-

1. as a response to GET /runs, /maintenance_runs and runs/{runId}
2. as a response to all /protocols endpoints that return an analysis result. The analysis result is simply the 'final run data' of a run with a virtual robot.
3. as a result of the analyze cli tool as well as the opentrons simulate and execute cli commands

[ddcc4]

Thanks for that info!

I think I want to handle the summary implementation in a separate PR, since this PR is quite large already.

Apparently, the StateSummary feeds into AnalyzeResults, which says it needs to be kept in sync with robot-server's model, etc., so there are a lot of places I'll need to update. I'll ask you later how those classes are related to each other. But I'd like to handle that in a separate PR, and merge this PR as-is.

[sanni-t]

Nice!!