Controlling number of vAMMs deployed

[davidsiska-vega]

At the moment we have:

• minimum vAMM commitment amount in quantum; this works as spam protection and if it was to be increased existing vAMMs stay, new ones have to meet the new minimum.

Clearly there will be an upper limit on how many vAMMs we can support in a performant manner (even if the upper bound is high). Several options seem available:

1. update the behaviour of the minimum to also remove those vAMM commitments that don't meet the new, increased minimum quantum. The danger is that cancelling parties' commitments isn't especially nice.

2. add a network wide parameter setting the maximum number of vAMMs allowed. This one maps the most cleanly to whatever performance impact large number of vAMMs may have

3. add a per market parameter maximum number of vAMMs allowed; advantage of having capability to add new markets with passive liquidity, disadvantage is that this number will either be low, limiting popular markets, or high but then it may not provide the required control of perf impact.

4. a network parameter setting (minPerMarket, maxTotal) interpreted as: if a party submits vAMM and the total across the network is below maxTotal it goes through. If the total across network is above maxTotal we check which market it goes to, if that market has fewer than minPerMarket then it goes through. Otherwise reject.

[davidsiska-vega]

Question: do we still need this since the "number of empty ticks between bounds in vAMM commitment" restricts the smallest size anyway and we're proposing to control this: #2358

[davidsiska-vega]

See benchmarks for performance impact.