Includes validating that the amount the other party commits to is the expected amount based on calculating the counterparty margin out of the CFD values.
Note: We could also remove the lock amount from the messages and use the calculation on both sides - that would simplify things.
Flattening the Cfd out in the internal mode has caused duplication and confusion.
This refactor puts the Order into the Cfd to make relations clearer.
Note that once we have multiple leverage the leverage and liquidation price will have to move into the Cfd because they depend on the user's choice then.
This should be trivial to do.
The buy margin is calculated from `initial_price`, `quantity` and `leverage`.
The sell margin is calculated from `initial_price` and `quantity` (no leverage trading for the seller at the moment).
Includes several refactors:
- Separate API interface for `Cfd` and `CfdOffer` when mapping `toSseEvent`. This allows internal modelling to be different than the exposed API.
- Remove the profit calculation internally, it is only relevant on the UI feed API level.
- Move code that is specific to taker/maker http API from `model` to the respective `routes` module.
- Some simplification of the calculation model of `Usd` (could be further improved by deriving calculation traits)
- Introduces `OfferOrigin` used to save the offer's origin as `mine` and `others` in the database. This is used to properly derive the CFD position from the offer.
Daniel Karzel