Implement submit multiple orders for Binance

[objectin]

Feature Request

Description

Implement the functionality to support multiple orders execution for Binance as per their official API documentation:

• Placing Multiple Orders (TRADE): API Documentation
• Modifying Multiple Orders (TRADE): API Documentation

Requirements

1. Placing Multiple Orders (TRADE)

• Endpoint: POST /fapi/v1/batchOrders.
• Weight: 5.
• Parameters include a list of up to 5 orders, timestamp, and various order details like type, symbol, side, quantity, price, etc.
• An example request is provided for placing an order.
• The response includes details like order ID, client order ID, symbol, and status.
• If the "ReduceOnly Order" is rejected, an error code and message are returned.
• Rules are mentioned for concurrent processing and order matching.

2. Modifying Multiple Orders (TRADE)

• Endpoint: PUT /fapi/v1/batchOrders.
• Weight: 5.
• Parameters include a list of up to 5 orders to modify, timestamp, and order details similar to placing an order.
• The response includes updated details like order ID, symbol, status, price, etc.
• An error code and message are returned if the "ReduceOnly Order" is rejected.
• Like placing orders, the modification of orders is processed concurrently, and rules are outlined regarding the order of matching and content return.
• An order can only be modified fewer than 10,000 times.

[cjdsellers]

This issue is now being actively worked on. We're introducing enhancements to how orders are handled in the system, particularly focusing on batch commands. Here's a rundown of the changes and new features being implemented.

Batch submit
The placing of multiple orders can be handled by the existing submit_order_list / OrderList (just needs implementing as such in the Binance client).

Batch modify and cancel
A new batch_more flag is being added to modify_order and cancel_order (default False to retain current behavior). This will control whether subsequent calls are batched into BatchModifyOrders and BatchCancelOrders commands respectively.

Intended behavior is described in the initial version of the docstrings:

• https://github.com/nautechsystems/nautilus_trader/blob/develop/nautilus_trader/trading/strategy.pyx#L647
• https://github.com/nautechsystems/nautilus_trader/blob/develop/nautilus_trader/trading/strategy.pyx#L708

Excerpt from docstring:

        batch_more : bool, default False
            Indicates if this command should be batched (grouped) with subsequent modify order
            commands for the venue. When set to `True`, we expect more calls to `modify_order`
            which will add to the current batch. Final processing of the batch occurs on a call
            with `batch_more=False`. For proper behavior, maintain the correct call sequence.

        Warnings
        --------
        The `batch_more` flag is an advanced feature which may have unintended consequences if not
        called in the correct sequence. If a series of `batch_more=True` calls are not followed by
        a `batch_more=False`, then no command will be sent from the strategy.

@objectin any thoughts/feedback on the above?

[objectin]

Seems nice, it will extremely helpful for handling multiple orders in a batch. And also for ratelimit problems when handling a bunch of orders.

[cjdsellers]

So I decided to go a different way for the case of the batch cancel, simply call this from the strategy now (passing a list of orders):

self.cancel_orders(orders)

This will create a BatchCancelOrders command under the hood and send it to the ExecutionEngine.

Now implemented for backtesting and Binance Futures on develop branch.
Tests OK for me live on the Binance Futures testnet, please let me know how it goes when you get a chance.

[cjdsellers]

Next up I'll implement the batch modify, which will probably follow the API which was first proposed ^.

[cjdsellers]

The batch modify involves larger changes to the core platform -- moving this to the backlog for now.