This will allow us to generically wrap a api model into a signed value model which covers the signature creation and verification.

Creates a hodl invoices, subscribes to updates to it and returns the invoice to the app.

Co-authored-by: Richard Holzeis <richard@holzeis.me>

Before the button was jumping depending on whether the slider or the button was shown.

I also changed the button text from "Confirm" to "Next" since there wouldn't be any semantical difference between funding with internal wallet or external.

The asterix was just not clear enough. I also did some minor styling improvements and removed the unused label argument from the fee expansion widget.

This will submit the order once a hodl invoice is paid.

In the next step we have to extend the post order api to revail the pre image so that the coordinator can claim the payment and open a single sided channel.

api.rs should remain as a thin proxy to the flutter frontend.

we need to store the pre image to be able to refer to it later again. Also, it will help us get a good overview of who asked for what.

if the trader receives the note that the ln invoice has been funded, he shares the preimage with him when creating a new order. Upon receiving said preimage, the coordinator checks if the preimage fits to a known hash in the db. Next: redeem payment before matching the order

this is needed because we send a url_safe base64 version over the via.

If we received the lightning payment from the user we open the channel to the user with only the coordinator's funds.

Co-authored-by: Richard Holzeis <richard@holzeis.me>

Otherwise, we might end up with "/" in the hash what will result in an endpoint not found error as the "/" is interpreted as path.

That should be enough to pay the lightning invoice and reduces the risk of price movements.