fix(api): remove invalid errors for lc positioning check

[sanni-t]

Replaces #18585

Overview

About the error removal

Until now we have assumed, and pushed for the assumption, that a submerge start point and retract end point should be above the aspirate & dispense locations of the transfer properties specified in a liquid class. This requirement was mainly added to avoid getting into situations where the submerge start location or retract end location could end up being inside the liquid, especially when we have no idea of the liquid's height inside well.

The above situation was a concern because it could mean aspirating liquid by mistake when trying to aspirate air gaps or move the plunger to prepare for aspiration at either the submerge start point or retract end point. But over the course, we have changed this behavior so that prepareForAspirate and addAirGap both happen above the well, always (#18653, #17800). So we no longer truly need to enforce the positioning requirement of submerge start & retract end.

Additionally, consider this example-
An LC-based transfer that wants to set its dispense location as 5mm below the liquid meniscus. Note that this is 5mm below where the meniscus would be at the end of the dispense. Let's assume this location is Point(10, 10, 10).
Assuming the destination well is empty in the beginning, one could set their submerge location to be Point(10, 10, 8) and that would be totally fine since this location would actually not be inside liquid. The tip should be allowed to start at (10, 10, 8) and then move up to (10, 10, 10) to dispense. But the current check didn't allow that.
There's a couple of more examples like this where a submerge/ retract point might lie below the aspirate/dispense points without causing any real issues but our code won't allow it.

Because of these reasons we want to remove this check that looks for order of these positions.
We will still be raising errors for when submerge start or retract end positions lie inside the liquid.

About log level change

Internal users complained that the warning is too verbose and happens way too often and it shows up in the default simulation output. So I'm changing this to an INFO level so that it won't show up in the output but will still be available in the logs as useful info.

Test Plan and Hands on Testing

• Updated tests. On-robot testing not required

Review requests

Do you agree with the two decisions above?

Risk assessment

None

[ecormany]

Not changing any user-facing text, so I defer to engineering reviews.

[sanni-t]

Not changing any user-facing text, so I defer to engineering reviews

It should change the output for opentrons_simulate such that it shouldn't see those warnings anymore.

[jbleon95]

Yup, I'm good with these changes, there was a way to silence the errors while doing simulate but it required some extra arguments and this way we don't alarm anybody unnecessarily while still logging if this occurred for debugging purposes.

[ecormany]

Not changing any user-facing text, so I defer to engineering reviews

It should change the output for opentrons_simulate such that it shouldn't see those warnings anymore.

Right, but those strings are all the same — if you know where to find them now. No wordsmithing needed 🙂