Actually should be called funding spend fee or taker payment fee, but we are just following the current code naming at the moment.

The negotiation goes as follows:
1- Taker and maker each decide how much this fee should be at the beginning of the swap.

2- The taker will send the maker their proposed fee during negotiation,
   if the maker deems the fee as low enough (less than 90% of the maker's own calculated fee),
   they will refuse to trade before the trade starts. Otherwise, they
   will continue and use this fee for validation later.

3- The maker will validate that the taker has accounted for this fee in
   the funding transaction.

4- The taker will validate that the taker payment preimage (generated by the maker)
   uses the negotiated fee or greater (greater number will deduct from the maker's trading volume anyway).
   If not, the taker will stop the trade since the maker is clearly stealing funds that isn't his
   which might affect the completion of the swap if the fee is low.

…o u64

The big decimal might be a fraction less than zero and gets converted to
zero when sent over the wire (because we send the fee as u64).

Scale it properly before sending it.

noticed this in the integration tests, the fee might be a fraction so
clamping it to one yields a fee higher than the actually one, thus fails
the ratio check

use a signature-size dummy date instead

taker payment spend is actually taker payment here, next commit should fix the naming inconsistencies

don't depend on no variable on this regard

… avoid weird precision

also changed to todo

revising the commit history, looks like this was deliberate

ref. https://bitcoin.stackexchange.com/questions/48108/why-are-sighash-flags-signed-as-4-bytes-when-only-1-byte-is-included-in-the-tran

always rename discuss markers to fixmes since i forget about them xD

there is no calculatable tx_size for other tx (non-htlc) (like funding and maker payment txs). their fees depend really on the utxos we have and whether they are segwit or not.
used get_sender_trade_fee for now, though I think this method needs reviewing since its doc comment doesn't make a lot of sense