Open order loading

[goodboy]

Ok so more or less this introduces 2 main things:

• _emsd_main() now delivers existing active "order msg dialogs" to every client that connects
• the EMS relay loop will process and relay unknown BrokerdStatus msgs to all connected clients (though likely we should change the msging semantics, more on this later)

---

Topics of contention and thus discussion:

• [x] what should be the msg type for relaying existing orders from a backend?
  • first draft was using BrokerdStatus but with hacked in extra fields and it's super ugly (as is this msg in general) and i'm wondering if we should support sending brokerd ->emsd->clientmsgs ofBrokerdOrderor at least some kind of embedded version of this (sayBrokerdStatuscontaining aBrokerdOrderwhich gets transformed to aStatuswith and embeddedOrder`?)
  • [x] ended up going with the brokerd just sending a Status with an embedded .req: Order which feels pretty natural actually and even more so if we end up dropping all the BrokerdX typed messages as well.

---

To defer in follow up work:

all moved => https://github.com/pikers/piker/issues/384

TODO for this to land:

• [x] use Status throughout ems and expect it from brokerd actors to load existing "live" orders
• [x] factor out the stock split hack in pp.py which was added to keep ib working during dev see https://github.com/pikers/piker/pull/383
• [x] add kraken support
• [x] make the paper engine report and thus load existing "live" orders in it's book

outstanding bugs:

• [x] kraken currently has the issue where the first loaded order their backend gives a userref of 1 which we then relay, but we don't compensate for this is the order request handler loop and thus can crash the ems on a double book id entry:
  • we either need a global reqid set or we need to figure out a different scheme
  • we could considering concatenating the oid from the ems with wtv reqid is delivered by each backend?
  • solved in => 2fdc146
• [x] connecting to a daemon-ems that had orders clear will "replay" those orders to the client which normally results in not what we want: notification reprints (on linux) and no fills annotations on chart..
  • this is currently due to a regression where we can't seem to deal with the race case from ib where a fill msg may get delivered after a closed status?
  • solution in => 7b6ace2
• [x] fix issue discovered by @guilledk where position msgs from paper engine show up in symbols that shouldn't have a paper position
  • this is likely due to global delivery of the piker.clearing._paper_engine._positions table to clients on connect from 7494b51, we likely need to fqsn-filter this table?
  • fix in => e9dde5d
• [x] fix ib with multiple accounts where the order mode UX isn't putting the correct account name in the level line label..
• [x] fix orders loaded from multiple accounts (again ib) such that cancelling doesn't cause an ems crash on book._active: dict reads. repaired in last 2 commits in #383

[goodboy]

This is more or less ready for code reviewing to start but still has some outstandings above.

[goodboy]

@guilledk can you do a once more over?

Fixed up multi-account order line labeling and made it so the settings pane adjust automatically depending on Order.account 🏄🏼