feature: add one-cancels-the-other (OCO) order group

[Romazes]

Description

Adds a one-cancels-the-other (OCO) order group. QCAlgorithm.OneCancelsTheOtherOrder places a take profit limit leg and a stop loss stop market leg together, both for the same quantity. Both legs rest in the market; the first one to execute ends the group.

C#:

MarketOrder(_spy, 100);
var price = Securities[_spy].Price;

// close the position at a profit or at a loss, whichever price comes first
var tickets = OneCancelsTheOtherOrder(_spy, -100, limitPrice: price * 1.01m, stopPrice: price * 0.95m);

Python:

self.market_order(self._spy, 100)
price = self.securities[self._spy].price

tickets = self.one_cancels_the_other_order(self._spy, -100, limit_price=price * 1.01, stop_price=price * 0.95)

The group can never trade more than the quantity it was given. When a leg executes, that quantity comes off every other open leg, and a leg left with nothing is canceled in the same order event batch. A full fill is just the case where the others reach zero. This also covers a partial fill: the stop selling 30 of 100 leaves the limit leg at 70, so the position keeps its target and the group never sells 130.

Main changes:

• New GroupExecutionType enum (Combo, OneCancelsTheOther) and GroupOrderManager.ExecutionType, serialized as executionType. Groups serialized before this keep loading as Combo.
• Order.CreateOrder and OrderJsonConverter attach the group manager to a plain Limit/StopMarket leg before its Id is set, so a leg restored from JSON stays in its group. Only combo order types carried the manager through those paths before.
• QCAlgorithm.SubmitGroupOrder is the shared submitter for group types that are not the ratio combo: it builds the legs' requests, runs every pre-order check before submitting any leg, and submits in list order. The conditional (OTO) and bracket orders add their own thin wrapper over it.
• BacktestingBrokerage simulates the group so backtesting and paper trading need no brokerage support. Legs are evaluated in a fixed order — stop legs first, then by id — and the first leg to execute any quantity ends the pass and reduces its siblings.
• Buying power does not double count the legs. A same symbol group only has to afford its most expensive leg, since only one leg can execute; a group across symbols checks every leg on its own. CashBuyingPowerModel stops counting a sibling's quantity as reserved, and GetProjectedHoldings and Shortable count one leg per group.
• HandleUpdateOrderRequest now validates buying power when a leg of a non-combo group is updated. Combo legs keep the old skip.
• No brokerage gate. A brokerage maps the group in its own plugin, and AlpacaBrokerageModel.CanSubmitOrder checks Alpaca's own rules per leg: 2 legs, US equity, limit or stop market, both legs on the same side, day or good til canceled.

Related PR(s)

Both are drafts that depend on this one:

• feature: support one-cancels-the-other orders Lean.Brokerages.Alpaca#74 — the Alpaca live mapping.
• feature: add one-cancels-the-other (OCO) group order support Lean.Brokerages.InteractiveBrokers#244 — the InteractiveBrokers live mapping.

Related Issue

#8253

Motivation and Context

First step of the bracket order plan: OCO now, conditional (OTO) next, bracket on top of both. A user can protect a position with a take profit and a stop loss pair without canceling the other one by hand, and without the risk of both filling.

Requires Documentation Change

Yes. The new OneCancelsTheOtherOrder API needs a page, and the brokerage pages need to say which brokerages accept the group once the two plugin pull requests land.

How Has This Been Tested?

Regression algorithms on SPY hourly, January 2019:

• OneCancelsTheOtherOrderRegressionAlgorithm (C# and Python) — the take profit leg fills, the stop leg ends Canceled in the same batch, and the algorithm ends flat.
• OneCancelsTheOtherOrderCancelRegressionAlgorithm (C# and Python) — canceling one leg cancels both, and the original market order fill is untouched.
• OneCancelsTheOtherOrderPartialFillRegressionAlgorithm (C# only, it needs a custom fill model) — the stop leg executes 30 of 100 and the limit leg has to shrink to 70. It asserts the leg quantity, not just the total, because a group that stopped early would also end flat.
• OneCancelsTheOtherOrderDemoAlgorithm — a manual aid for running the group against a live or paper brokerage. It does not implement IRegressionAlgorithmDefinition.

Unit tests:

• BacktestingBrokerageTests: LegFillCancelsSiblingInSameEventBatch, StopLegWinsTieOverLimitLeg, CancelingOneLegCancelsWholeGroup, CancelOrderLeavesAlreadyClosedLegUntouched, TimeInForceExpiryOnAnyLegCancelsWholeGroup, PartialFillReducesSiblingsAndGroupStaysPending, GroupIsProcessedOnlyOnceExactlyPerScanDespiteTwoPendingEntries.
• AlgorithmTradingTests: the two tickets come back limit first and share one manager; a zero quantity returns one invalid ticket; the tag and order properties reach both legs; Liquidate cancels every leg of an open group.
• BrokerageTransactionHandlerTests: the legs buffer until the group is complete, a submit time failure invalidates every leg, and the update path validates buying power for OCO but not for combo.
• SecurityPortfolioManagerTests and CashBuyingPowerModelTests: the most expensive leg rule, and a cash account holding exactly 1 BTC can place the sell pair through OneCancelsTheOtherOrder.
• OrderJsonConverterTests and OrderTests: a plain leg keeps its group over two round trips, and old JSON without the field loads as Combo.
• AlpacaBrokerageModelTests: a valid group passes, and each of the five per-leg rules rejects on its own.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>