[Feature]: AMM improve calculations to the orderbook shape for wide bounds

[wwestgarth]

Feature Overview

For the purposes of ELS calculation, on each block the buy-side VWAP and sell-side VWAP of each AMM is calculated by "expanding" the pool's curve into physical orders at each price level. This is done in a method called .OrderbookShape().

For pool's that are narrow on markets with a reasonable number of decimal places, this is an ok thing to do. For a pool that is wide, or where a market has a lot of decimal places this approach will not work.

For example consider the case where we have a market with 5 decimal places and the pools curves are set as:

lower:  1.00000
base:   2.00000
upper:  3.00000

Calculating the VWAP here would require expanding into 200,000 orders each and every block. If we had 10 such pool's that would be 2,000,000 orders. This will have a large impact on block-time, so we need to be clever.

Things we can do:

• calculate an approximate VWAP by combining price levels and sampling the curves capped at some maximum number
• a hard limit on the total number of price-levels an AMM can span, and it gets rejected on submission if its too wide
• change the ELS calculations such that we do not need to expand an AMM's curves into orders

Specs

• Link to spec or section within a spec

Tasks

A checklist of the tasks that are needed to develop the feature and meet the acceptance criteria and feature test scenarios.

• [ ]
• [ ]

Feature test scenarios

Detailed scenarios that can be executed as feature tests to verify that the feature has been implemented as expected.

GIVEN (setup/context) WHEN (action) THEN (assertion) For example... See here for more format information and examples.

Additional Details (optional)

Any additional information that provides context or gives information that will help us develop the feature.

[wwestgarth]

Blocked until we've run this by protocol-design to land at a way forward.

[Sohill-Patel]

the system-test test_amm_lifecyle when run with its usual precision for a market which is 5dp, submitting an amm takes around 7s and that breaks the test.

Here is an example of one such run https://jenkins.vega.rocks/job/common/job/system-tests-wrapper/58446/ the slow block is 194

ONE OR MORE SLOW BLOCKS DETECTED DURING THIS TEST. IT **MIGHT** BE RELATED TO YOUR FAILURE. PLEASE DON'T BLAME IT WITHOUT FURTHER EVIDENCE. BLOCK TIMES FOLLOW BELOW FOR CONVENIENCE. (NOTE, THESE ARE CALCULATED BASED ON VEGATIME, WHICH IS WHEN VEGA THINKS IT CREATED THE BLOCK, NOT WHEN TENDERMINT COMMITTED IT. 
194: 2024-05-15T15:02:13.658835809Z (6.911412000656128 secs)

that coincides with the time we submit the second amm which is when vega tries to create the pretend orders at every price level

https://jenkins.vega.rocks/job/common/job/system-tests-wrapper/58446/artifact/test_logs/amm/amm_test.py/test_amm_lifecyle/BUS_EVENT_TYPE_AMM.txt

[wwestgarth]

Raised with protocol design here: https://vegaprotocol.slack.com/archives/CAHA5EX0F/p1715850840208469

The way forward is to seems to be:

• only break down the AMM into 10 orders, and not at every price level, controlled my a network parameter
• randomly select an AMM with some probability to do the SLA calc on instead of doing all of them

Note that the limiting of how many orders we break down an AMM into has been added in: https://github.com/vegaprotocol/vega/pull/11316