feat: tx trade ordering

[TomMcL]

Closes #2232

[Vegaklaus]

Some comments on the implementation (given that interacts with other planned features)
It would be nice if the delay function could also delay by several blocks, as that would be halt of the integration of order policies in Wendy. I.e., a flow like
0. Keep an extra delay-buffer with delayed transactions and some meta data (e.g., how long has this transaction been delayed yet; can be more in the future)

1. Increase the 'has-been-delayed' counter of all transactions by one
2. Take all transactions out of the tender mint buffer into the delay-buffer with 'has-been-dalayed'=0
3. [For future optimisations: Release CBFT to process the next block to parallelise block evaluation with the consensus. Assure that CBFT is only ahead by one block to avoid too much asynchrony]
4. For all transactions in the delay buffer, run a function that verifies if they can leave the buffer now. This implements only the function from this spec now, but can be extended by additional policies that also may be market-dependent
5. Remove all functions that can be delivered from the delay buffer, and sort them by the second ordering function (which also might be extended in the future)
6. Run a transaction validity verification on every transaction again (as the state of the system may have changed in the meantime), and feed all valid ones into core.
7. If a transaction has been delayed too long (e.g., 50 blocks), it is dropped (or immediately delivered ,that's up to discussion)

[Vegaklaus]

We should probably add some implementation discussion here to make sure we're all on one page and this doesn't interfere poorly with other (planned) features; my understanding so far:

• delaying by a block is done post-consensus, i.e., a (block) delayed message is put in a special buffer and then added to the next block
• in-block ordering takes both the current block and the delayed transactions, and then re-sorts
• If we add other order policies (e.g., Wendy), this should then use the same code here - otherwise we may end up with conflicting order requirements at different places.
• For now, a transaction needs to be delayed only for one block, but that may change in the future
• Being able to take a message from consensus, put it run a buffer, and execute it later is also a good part of the work for asynchronous execution (i.e., execute the core code while CBft processes the next block)
• We need to make sure the post-consensus transaction validity check is still sufficient if transactions can be delayed more (it should be)

[davidsiska-vega]

Do we need a netparam to enable / disable this re-ordering? @barnabee / @TomMcL

[barnabee]

Do we need a netparam to enable / disable this re-ordering? @barnabee / @TomMcL

Ideally yes. I know an early version of the spec had this per market, which is most ideal but we were also willing to drop that if it added excessive complexity and just have a network wide switch.

I would assume "disabling" this (whether per-market or net wide) would basically mean something like treating every order/market instruction for which the feature is disabled as if it was given the high priority, or some equivalent.

Probably need @ze97286 input here as to what is built and what makes sense…

Ancient.