Fixed bug where if trailstop order is triggered it would sell [buy] at the high [low] of a bar.

[Bosma]

Previously:
at line 376 a new order replaces the previous trailstop order with order price
new.order.price - order.threshold
since the order is being replaced, we can say
new.order.price != orderPrice
and in the long case, this means
new.order.price = previous_bar_high + order.threshold
therefore, the new order price on line 380 is:

price = new.order.price - order.threshold
      = previous_bar_high + order.threshold - order.threshold
      = previous_bar_high

Since, in the long case, the next bar is most likely under
the high of the previous bar, the order is fired and you sell
the top of the previous bar.
analogous for the short case.

So, the order.threshold subtraction on line 380 was removed, since
the threshold is already considered in line 366 and 368.

[joshuaulrich]

If this corrects the OHLC case, it seems like it should also be applied to the BBO case. We currently subtract orderThreshold in L328, even though it's been accounted for in new.order.price in lines 300 and 314. Thoughts?

[Bosma]

It looks like it also needs the change I submitted. I don't understand why lines 301 and 315 aren't uncommented, since if mvstop is true, new.order.price is always set to mktPrice - absThreshold. It would only be set to orderPrice is mvstop is false, but nothing happens in that case.

added commit to change that, too.