refactor(api): clean up liquid class transfer code

[jbleon95]

Overview

This PR has minor refactor work for the instrument core implementation of liquid class transfers (those being transfer, distribute and consolidate), mostly to reduce the amount of repeated code between the three functions. The areas refactored are:

• Drop tip and pick up tip logic for liquid classes, which was the largest chunk of repeated code between the three and now exists within its own private function
• Getting the transfer properties and resulting error handling, now in a private function
• Getting the working volume given a tip rack labware core, this is not private though it has not been added to the instrument core interface
• Getting the sources and/or destinations and volume splitting has been put behind another function that encapsulates the getting of properties and handling the difference between multi dispense and regular dispense

Test Plan and Hands on Testing

Pure refacotr only, so existing unit tests, integration tests and snapshot tests should cover any regression.

Changelog

• Refactored instrument core liquid class transfer code to remove repeated code and encapsulate more elsewhere

Review requests

Do we agree with these refactors, in that they make the code easier to follow? Is there any other area we'd like to see refactored?

Risk assessment

Low, these changes are pretty straightforward and a diff checker was used to ensure that all code refactored was in fact the same.

[ddcc4]

Would it be clearer to move this if robot_type == "OT-2 Standard" up above the try? Or do you always want to attempt the lookup even if it's an OT-2?

[ddcc4]

Wait, I guess you do always want to try, because PD generates a liquid class for the OT-2.

[ddcc4]

Although the error message is a bit misleading for the OT-2 then?

I.e., say we are on the OT-2, and the user has specified a custom liquid class for the pipette, but they gave the wrong name for the tiprack they're using. This function would fail with the error message Default liquid classes are not supported with OT-2 pipettes and tip racks, which is less helpful than the default message of No properties found for {tiprack_uri} for {pipette_name}.

[jbleon95]

Hmm, yeah I see what you're saying. There's two things I wanted to accomplish with this error message (which was added in an earlier PR): make it clear that no OT-2 pipette and tip rack was supported by the default liquid classes (rather than saying a certain pipette and tip rack were unavailable, which many give someone the idea that other OT-2 combinations may be possible), while also allowing for it if the user added it in some way (editing json, PD, custom liquid classes, etc). But you're right in that the existing error message gets in the way of the second case if the user provides the wrong pipette/tip rack. I'm not sure what the right solution is. Maybe we raise a different error for a wrong tip rack when a pipette exists? Check if any OT-2 compatible pipettes and tip racks exist?