This PR does a few things:
* cleans up the SQL to make the queries clearer in terms of intent, as well as eliminating the use of an extra transaction in some write queries.
* adds some additional testing
* (mostly) eliminates the use of `serde_json::to_string()`, making the data columns behave in a more sane manner
We are only making requests to Olivia that are absolutely necessary,
i.e. only fetch attestations when they are likely ready and only
fetch attestations that we definitely need.
As a result, we can trigger the sync much more frequent.
Fixes#349.
We almost always have the entire `Cfd` available when we call this
function. It is therefore much easier to simply pass the entire
`Cfd` in instead of selective data.
Upon rejection, we always have to remove the order on the maker side, otherwise a taker cannot re-try taking (with e.g. a different amount) because there is already a rejected cfd in the taker database.
We would have liked to attach the stream of `TakerStreamMessage`s
directly to the `MessageChannel`, but we failed and instead decided to
let the `maker_inc_connections::Actor` send these messages to itself
and then forward them to the `maker_cfd::Actor`.
Inserting cfd or updating its state requires a follow-up update on the Cfd feed
sent to the UI. Encapsulate the behaviour in functions that are shared
across Cfd actors.
Once we have collaborative close present in the state(s) we lock in the profit based on the price of the collaborative close.
Note: Currently no automated validation on the maker side if the given amounts and price of collaborative settlement are sane.
Simplify model's state machine as PendingClose only matters for the UI
(for user feedback & available actions).
Disallow proposing another settlement if one was already signed.
The primary goal was to remove all of the calls to `serde_json::to_string()`
for the data-handling, thus enabling us to do (more or less):
```rust
Order {
row.column,
...
}
```
as well as clean up the SQL for easier reading. This has mostly been
accomplished, with further refinements easily accomplished once the
upstream issues in `sqlx` are addressed. See #314 for issues we are
tracking.
A fan-out actor takes an incoming message and forwards it to a set
of actors. This allows our `oracle::Actor` to be unaware, how many
other actors are interested in the attestation, thus simplifying it.
Anything that can fail (e.g. fetching oracle stuff) has to be tried before we change any state or notify the taker, otherwise it can happen that we remain in a failed state that causes very weird side effects.
Lucas Soriano del Pino
Thomas Eizinger
Daniel Karzel
DelicioiusHair
Mariusz Klochowicz
Philipp Hoenisch