Basic buy bot

[goodboy]

Finally a first rough draft of an automatic trading bot using multiple subsystems throughout the codebase 🏄🏼

Currently this example just loads an order client and live data feeds and then submits a trailing buy order that shouldn't clear:

• presuming ems handling is fast enough; keeps the price 0.004%
  below the last clearing price.
• uses the internal paper engine such that order updates are more
  or less as low latency as they can be given we have no serious
  clearing model (yet) inside.

---

TODO:

• we need some wrapping to make the order control API(s) higher
  level to ideally better encapsulate many of the runtime boot details:

  • ideally open_ems() hides all of:

    • OMS seems to be a suit acro? https://www.investopedia.com/terms/o/oms.asp

    • maybe_open_pikerd() which we should just be able to factor
      inside it right? don't think there will be any conflicts with
      existing UI driven boot sequence?

    • possibly returns a "higher level API" which wraps a bunch of
      lowlevel concurrency stuff and data feed(s) hookup:
      a OrderBook or something?

      class OMS:
          client: OrderClient  # EMS ctl
          dialogs: OrderDialogs  # msg flow tracking
          feeds: list[Feed]  # access to all rt and historical data?
      
          # SC interface to mange order dialog lifetimes?
          @acm
          async open_order(
            self,
            order: Order,
          ) -> Dialog:
              '''
              Open a new order submission with pedantic lifetime
              control:
                - automatically exit on error or fill
                - cancel on error-before-fill or on exit from block
                  before fill?
      
              '''
              ...

    • open_feed() + Flume loading and .mkt: MktPair
      processing to enable some kinda
      HighLevelOrderClient.order() which automatically has the
      price_round()
      pre wrapped?

    • wrappers for rt tick processing and FSP flow access?

      • will be intertwined with the evetual development of a shm
        tick buffer as per Cross-actor, shm, (tick) ring buffer #107
      • see .data.ticktools for some starter utils that are
        likely useful to wrap in and document usage..

    • a background task which constantly reads from the
      brokerd stream such that overruns never happen and
      sync-style code can easily read from some Status msg
      queue using poll-style?

    • a DSL of sorts that makes using async/await style
      code to manage order req/resp processing more terse?

      • more or less somthing that will offer the conditional
        functionality to await statuses from
        https://github.com/pikers/piker/pull/526/files#diff-0242f8b50a515bb4be7c360a7b54a860e50039117fe13c950bd75969dfdd3027R33
        much easier to grok and write as part of a more
        sophisticated algorithmic trading strategy..?

• lib code to conduct backend roundtrip submit-cancel latency
  measurement and expose it as a reliablity metric / FSP for
  driving order routing B)

[goodboy]

bleh, those last 2 commits needs to be squashed obviously 😂