Add trailing stops for OrderFactory bracket orders

[stefansimik]

Feature Request

Problem Statement

There is request from the community for convenient building of bracket orders with trailing stops for OrderFactory,
so user does not have to build them up from the scratch.

Discussion / context:

• https://discord.com/channels/924497682343550976/924506736927334400/1362219799568187402
• and 3 messages below it

Discord preview here for convenience and quick context:

[hope2see]

@cjdsellers Can I proceed with this?

[cjdsellers]

Hi @hope2see

Absolutely, and thank you for the offer.

I think that we don't want to touch the already large bracket(...) method, but add a new bracket_trailing(...) method which calls a common inner _bracket(...) method to reduce duplication.

What are your thoughts?

I'm also assuming you're wanting to add support for the activation_price parameter for this new method as well #2573?

[hope2see]

@cjdsellers
I think, from the viewpoint of implementer, adding a new bracket_trailing(...) method could be better. But, I wonder if it is also good from viewpoints of API users. Users may want to test diverse order types for making a bracket order. If they have to use different methods according to order types, it might cause inconvenience.

And, yes, I want to support the 'extended' features of trailing stop orders. :)

[cjdsellers]

My only concern is we've had confusion in the past as to the meaning of some parameters (or others are not noticed). There are probably too many already at 32, and adding the ones necessary for trailing stops (3-4?) only increases the chance of confusion.

[hope2see]

Right. Too many parameters..

How about grouping parameters by order type—one group for each of the three orders—while keeping the common parameters as is? While introducing an additional layer of abstraction may feel a bit heavy, it can improve the clarity and flexibility of the interface.

OrderList bracket(
    self,
    InstrumentId instrument_id,
    OrderSide order_side,
    Quantity quantity,
    bint quote_quantity = False,
    TriggerType emulation_trigger = TriggerType.NO_TRIGGER,
    InstrumentId trigger_instrument_id = None,
    ContingencyType contingency_type = ContingencyType.OUO,

    dict entry_order_params = None,
    dict tp_order_params = None,
    dict sl_order_params = None,
) 

[cjdsellers]

@hope2see

Yeah, I don't think introducing another layer of abstraction with dicts is the way to go.

I think just creating another method on OrderFactory specific to all of the additional trailing stop params necessary is the most straight forward? Then by using an inner _bracket method we can avoid duplicating all of the order creation logic.

[hope2see]

Let me make it clear.
From what I understand, you’re proposing a new method for bracketing trailing stop orders alongside the existing one. If so, the new method would essentially be a superset of the current one in terms of its interface. Is it right?

[cjdsellers]

Yes, at least one new method alongside the existing one, which is more specialized.

Another option could be to add:

• bracket_trailing_stop_market
• bracket_trailing_stop_limit

Which would constrain the order type for the SL and remove a few parameters?

[hope2see]

Ah, now I see the gap between our intentions.
I intended to use trailing stop orders not only for stop-loss, but also for take-profit.
That would maximize the utility of trailing stops by allowing a wider range of strategies.
Is there a specific reason why trailing stop orders should be limited to stop-loss use only?