Positioning system design discussion

[goodboy]

After landing the (very exciting) pair of patch sets in #462 and soon #470
this is yet-another-follow-up issue, with todos surrounding our pps.toml format, file management, and general position tracking service architecture.

---

We currently have a variety of follow up issues and bugs:
accounting prolly positioning: the accounting of "what/when (is) owned"

Some ideas that came out of the above mentioned patch sets include:

=> now all detailed in the newer #510

• we probably in the longer run need a new sub-service (actor-daemon): ledgerd
• changing our pps.toml .clears table-field format and name:
• there are a variety of order mode pane UI bugs particularly to do
  with limit adjustments as discussed in order mode pane UI bugs.. #479
• we should probably consider breaking up the singleton pps.toml
  into multiple files, likely broken up by broker and possibly by
  account
  => lands with Rekt pps? problem? => piker.accounting #489
  • this would also solve the data race issue with multiple
    brokerd's trying to write to a common file by instead expecting
    each actor-process to manage its own <brokername>_pps.toml
    file, allowing for distribution over multiple hosts as well as
    isolation between position state tracking if we were to route
    orders for a single pair through multiple brokers.

---

NEW MktPair struct format

As per the draft type that will land in
https://github.com/pikers/piker/pull/470/files#diff-2ea622b63a72576d8a27f1a2ab910591a350d29e7b6e0b9a055e49ae66626f12R137,
we want a much simplified and better suited for our fqsn market
addresing schema detailed in #467.

• landed with Rekt pps? problem? => piker.accounting #489 B)

likely i will write up some further details on how to refine this
prototype and use throughout the rest of piker's subsystems..here 😂

^Again see #489

[goodboy]

Bleh ended up moving pretty much all this content into new issues as mentioned above 😂