Enable order_id to be assigned before an order is placed by optionally specifying sequence for a new order

[crocodiledundalk]

We have a use case where we'd like to 'hold back' orders and within a queue for a 'waiting period' before they are cranked onto the orderbook. We would like it to be possible for users to uniquely and specifically identify their order, regardless of whether it is still 'waiting' in the queue or on the orderbook. For that reason, it would be great if there was some way to assign or anticipate the order_id that will be assigned to the order before it is posted to the book.

If applied, this holding period would apply to all orders, and therefore the sequence would still be respected (in that a subsequent order would always strictly have a higher sequence number). Although it would be possible that a sequence number might be 'skipped' - i.e. an order is cancelled while 'waiting' and before being cranked onto the orderbook.

One approach might be to add an optional parameter - seq_number to the new_order instruction which would be used when deriving the new order_id, otherwise derive it as currently implemented.

In this way, the calling program could use event_queue.gen_order_id(limit_price, side) to assign an order_id without placing a new order, noting and recording the sequence number used in generating this. When the order is cranked onto the orderbook, the calling program could pass an optional seq_number parameter which would be used to derived the order_id which is consistent with the previously assigned order_id.

[Henry-E]

In serum v3 (and now v4) they have implemented a client_order_id where the client can choose their own order id to look up some order. Maybe it would be possible to have some internal_order_id on the program calling the AOB?

[crocodiledundalk]

We had implemented something like this initially but felt the proposed might be a better result, as:
(a) it requires the callback_info to be increased in bytes in all cases, and not just when this is required
(b) you would need to use a different identifier (and possibly a different ix) to cancel the order depending on whether the order was still in the queue or if it had made it onto the book.