fix(CL): error blow up in CalcAmount0Delta causes OverChargeSwapOutGivenInError when swapping zero for one

[p0mvn]

Closes: #6351

What is the purpose of the change

See #6351 for detailed context.

Our current order of math operations in CalcAmount0Delta was causing error blow-up. This was noticed pre-CL launch but was deemed as acceptable due to occurring infrequently.

By lowering our min spot price to 10^-30, the frequency of this error occurring was increased to an unacceptable degree.

The core of the issue is that a / (b * c) amplifies the error when b and c are both small. Division by extremely small numbers has such an effect.

By changing the order of operations to a / b / c , we reduce the error amplification and resolve the problem encountered.

The test added on this branch reproduces the edge case (expected results are estimated in Python).

Made changes to the new test helper in osmoassert as a drive-by change

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes?
• Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

• Specification (x/{module}/README.md)
• Osmosis documentation site
• Code comments?
• N/A

[github-actions]

Important Notice

This PR modifies an in-repo Go module. It is one of:

• osmomath
• osmoutils
• x/ibc-hooks
• x/epochs

The dependent Go modules, especially the root one, will have to be
updated to reflect the changes. Failing to do so might cause e2e to fail.

Please follow the instructions below:

1. Open https://github.com/osmosis/osmosis/actions/workflows/go-mod-auto-bump.yml
2. Provide the current branch name
3. On success, confirm if an automated commit corretly updated the go.mod and go.sum files

Please let us know if you need any help.

[AlpinYukseloglu]

LGTM, nice job finding a clean fix for this. I left a non-blocking comment about rounding direction (still approving since rounding direction at precision doesn't matter here as long as we Ceil at the end)

[p0mvn]

@AlpinYukseloglu Thanks for the review, made some extra updates to apply the same order of operations when rounding down:
f8fb807

[AlpinYukseloglu]

Updates LGTM! Rounding at precision in intermediate calcs might be overkill here (in the original implementation as well) but as long as rounding error doesn't blow up anywhere later I think it's good to keep

[p0mvn]

Looks like this resolved the sub-ULP issue we were having pre-launch judging by the failing test that was reproducing it:

osmosis/x/concentrated-liquidity/swapstrategy/one_for_zero_test.go

Line 162 in d4ad039

"7: invalid zero difference between sqrt price current and sqrt price next due to precision loss, full amount remaining in is charged and amount out calculated from sqrt price": {

Going to look into it now

UPDATE: The edge seems to be fixed, the zero sqrt price difference does not occur anymore.

Updated the value out. Recalculated it in Python: d4ad039

Added comment that the edge case was fixed: a8e4284