fix: improve dust handling in EstimateTradeBasedOnPriceImpact

[migueldingli1997]

What is the purpose of the change

We've noticed that the EstimateTradeBasedOnPriceImpact introduced in #6167 can error when we're estimating a dust trade against a balancer pool. This happens especially if the weights of the base and quote assets are equal, meaning that for a small enough input, the pool might only be able to give out <1 tokens, which is rounded to zero and triggers an ErrInvalidMathApprox.

This PR adds logic to look out for ErrInvalidMathApprox in the case of balancer pools, in which case this error is tolerated and a zero output is returned instead of the error. Some refactoring to reduce code duplication was also applied.

Testing and Verifying

This change added tests and can be verified as follows:

• Added unit test case that specifically checks that we can estimate the trade output from a 1 token input into a balancer pool.

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

[mattverse]

Thanks for the PR! Good catch.

I think there are two components of this PR.

1. Err checking if err returned from calculation is ErrInvalidMathApprox, if so graceful returning zero instead of treating this as error
2. Refactoring functions in router.go with wrapper functions that create response (e.g ZeroEstimateTradeBasedOnPriceImpactResponseOnErrInvalidMathApprox, ZeroEstimateTradeBasedOnPriceImpactResponseFromRequest)

I am very much in favor of part 1, but I think the new methods introduced with wrapper functions that calls another function to create response struct can be overly confusing compared to directly creating and returning response struct in router.go. Please take a look at let me know what you think! :)

[migueldingli1997]

@mattverse I removed the confusing helper functions sir

[mattverse]

Awesome! LGTM

Note to other reviewers: This change is state breaking due to us having estimate query for stargate query

[migueldingli1997]

@mattverse is this pending another approval or can it be merged?

[mattverse]

@migueldingli1997 Just waiting to see if any other folks are willing to review this. Planning to merge this by EOW if not