feat(api): add aspirate_flow_rate/dispense_flow_rate to mix()

[ddcc4]

Overview

Add the aspirate_flow_rate and dispense_flow_rate absolute flow arguments to the PAPI mix() function. AUTH-1624

This follows the theme of adding absolute flow rate support to the InstrumentContext functions that previously took a rate ratio.

PD allows you to independently specify the flow rate for the aspirate and dispense in a Mix step, but the PAPI mix() function previously only allowed a single rate argument, which is a ratio that is multiplied by the pipette's default aspirate and dispense flow rates. (PD step generation worked around this limitation by changing the pipette's default aspirate/dispense rates for every Mix step. This change will let us generate simpler code.)

Test Plan and Hands on Testing

Added unit tests. You should be able to set one or both or none of aspirate_flow_rate and dispense_flow_rate.

Risk assessment

Medium. We're changing the public API.

[jbleon95]

I'd rather us remove an old test that might have questionable value than using hacks in our production code to work around it. What is the problematic test in question?

[ddcc4]

What is the problematic test in question?

It's protocol_api_old/test_context.py, like mentioned in the comment. It has a number of problems:

• The mock functions in that test (fake_aspirate() and fake_dispense()) have totally different argument names from what's in our current API (e.g., fake_aspirate() takes vol and loc, whereas our API takes volume and location). That means we can't even call aspirate() and dispense() with named arguments, because it would break the test.
• The mock functions in that test also has different default arguments from what we have in the API (e.g., fake_aspirate() takes rate=None, whereas our API takes rate=1). That makes it hard to write code that works the same with both our API and that test.
• The expected calls in the test are very specific, which makes it hard to add new arguments to our API.

So ... I think the test is annoying, but I don't know the history of the test and why it's there, so I'm afraid to just change the test, because it might be enforcing some behavior we need to preserve for ancient versions of the robot stack or something.

[ddcc4]

OK, I've removed the silly kwargs workarounds now that we no longer need to support protocol_api_old/test_context.py.

[jbleon95]

All looks good!