remodel paid actions schema

[huumn]

Notes for 7e93200:

These are my WIP schema changes. They haven't been integrated with the rest of the schema yet, because the changes will be dramatic.

---

Notes for 366c069:

I'm finding that it difficult to refactor without practically rewriting - mostly due to supporting multiple payment methods simultaneously and atomically. I'll likely create a minimal parallel implementation of PayIns (formerly "paid actions") first that meets all the requirements, then merge it with the old code. Presumed order of operations:

• parallel schema/state machine
• replace existing schema/state machine
• backend->frontend refactor
• test a lot
• migrations from existing schema

Some notable additions to the state machine are:

• new state PENDING_INVOICE_CREATION which is needed because we don't know the invoice amount in advance when paying partially with CCs/reward sats
  • this also means that we'll have a PayIn record before we know if invoice creation succeeds, so in the case that a P2P invoice is impossible to create, we'll need the ability to retry server side to support CC fallback
    • this will be written in such a way that client side retries can use it
• recording the reason for entering a FAILED state as an enum
• recording the time of any state change

---

This PR aims to accomplish:

1. simple and fine grained satistics gathering - per customer and in aggregate
   • PayIn will have ALL customer spending with a type
   • PayOut will have ALL customer earning with a type
2. trivial audibility - which assets were spent and earned, and what the effect of the action was on the balance of the assets for each the spender and earner
3. multiple payment methods for the same "action", e.g. 20 CCs + 20 reward sats + 60 sat invoice for an "action" that costs 100 sats while maintaining audit-ability and atomic refunds
4. realtime revenue for territory founders (this was not intended but was a bonus of the design), i.e territory revenue is not paid out each night anymore ... it happens when the action happens
   • similarly, actions that increase the rewards pool are no longer deduced but represented by a row in PayOut
     • consideration was given to future plans like territory-specific rewards pools and the design is conducive to that
5. the design should greatly improve the readability and reliability of retries and auto-retries
   • I haven't explicitly considered this in the design tbh, but given that we aren't overloading Invoice and Withdrawl with state, intuition would suggest this is the case. Regardless, wip/tbd.
     • This should be doable with a predecessorId in PayIn where each retry creates a new PayIn record
6. "prisms" (to be implemented later using the fact that PayOut is decoupled from PayIn)