Actions queue overflow in dealer::process_queue

[unboxedtype]

In Flex, orders of opposite direction get matched in the dealer::process_queue() function.

This function contains the while loop that traverses the order queues of opposite direction, matching orders with each other.
It is quite message-intensive function: for example, it generates at least 3 new messages for each partially matched order
(see dealer::make_deal), and on each loop iteration, it generates a message for every expired order found in the queue
(see dealer::extract_active_order).

The proposition of this issue is that in some circumstances, the process_queue() function may generate more messages
than allowed by the node, i.e. MAX_ACTIONS = 255.
(see https://github.com/tonlabs/ton-labs-executor/blob/e20b16b4d92cee8261e96916b118c344483e0013/src/transaction_executor.rs#L488)
If this happens, most probably, the Price smart-contract will not be able to match orders of this price level any further :
all future calls will run into the same transaction abort, leaving all the funds locked and this Price level locked.

Before doing the formal analysis, we thought that the number of generated messages is bounded by at least the deals_limit_
constant, but, it turns out, the loop iteration counter may go well beyond that value. And the reason is that the break statement is located under conditional that might not hold, leading to another loop iterations:
https://github.com/tonlabs/flex/blob/3aaa20eb73e7498d08d39191d693f1efa7d016eb/flex/Price.cpp#L139

It is proposed to introduce some definitional bound for the number of iterations this loop may process, hence protecting
the action queue from possible overflow / deadlock condition.

The same holds for PriceXchg::process_queue().

[unboxedtype]

Same holds for PriceXchg.cpp,
https://github.com/tonlabs/flex/blob/ededddc1ea37f7e40297ed5aafe06d5e4c1ff870/flex/PriceXchg.cpp#L158

[azhogin]

in the new version added calculation of out messages and overlimit checks.