Price improvement e2e test

[squadgazzz]

Fixes #2534

Those e2e tests are also required to be refactored and unified into a single test case. This will be done in a separate PR.

[sunce86]

Lg, although it's a bit unclear what actually happens under the hood, since we see only two random numbers in the test. Might be useful to add a comment similar to other tests (this can be recovered from existing logs and/or by adding temporary logs to observe execution)

[squadgazzz]

Might be useful to add a comment similar to other tests (this can be recovered from existing logs and/or by adding temporary logs to observe execution)

Added a comment, but not sure how to properly reflect the price limit adjustments based on the quote.

[fleupold]

Is this execute_test wrapper really necessary assuming we get rid of all the redundant surplus test cases and just keep 3 cases (surplus, price improvement and volume fee)? I think having three more verbose test cases would be better.

Maybe we could use more meaningful values (currently it seems like these were derived by running the test once and adjusting the values to what the test created) so it might not be that useful. But then, I also don't want us to go down the rabbit hole of redesigning the whole test infra like we did in the driver crate. Is it possible to use limit orders to ensure predictable match amounts?

Otherwise we can maybe do something like

1. Seed a bit of liquidity on the AMM that serves the token pair
2. Get a quote (which we use for placing the order)
3. Inject more liquidity into the AMM (this should improve the price)
4. Get another quote which we can do to do the math of how much the user should get in the end of the day.

This way it would be a bit easier to follow that these long digit series.

[squadgazzz]

Will be tackled in the #2468