Prevent dust outputs from being created during the trade process

[ghost]

This change fixes an issue whereby dust change outputs are inadvertently created during the trading process, unbeknownst to the user. The dust outputs cause the Bitcoin node to reject the
transaction and the trade then becomes stuck.

The solution taken here is to detect a dust TXO during the trade process and remove it from the transaction before broadcasting. This applies in both making an offer and/or taking an existing offer. When a dust output is prevented, it will be noted in the log as follows:

Related to #4039

[ghost]

I neglected to mention that this initial commit only handles the path taken when BTC is used for the trading fee; when BSQ is used the transaction is built by a different routine so some work will be needed to check for dust in the same way there.

Also, a bit sloppy that I check the dust limit using a hard coded 546 sats value; preferences.getIgnoreDustThreshold() could be used which equates to 600 sats currently.

[edit] both these issues have now been addressed.

[sqrrm]

Looks functionally correct and easy to follow. Would be helpful with a comment on how this works and what the effects are, perhaps around the removeDust method

Please review inline comments

[sqrrm]

I think this will cause BSQ change that lower than dust to be used as extra fee. That could be a non trivial amount (5.46 BSQ > USD3). While that's not a huge amount it's still too big to be an acceptable loss for users. If BSQ prices rise it will become even less so.

I think we'll have to fail transactions that try to pay the fee using BSQ if the change is less than dust. Best would be to show something at the time the fee is selected that it's likely to result in a dust change output and thus not be possible to continue. I think that should be doable, the fees are known at the time of setting up the trade so we can calculate the BSQ dust. One thing we need to do is make sure that if there is enough BSQ but split over 2 or more outputs, it's aggregated to avoid dust outputs. Example, counting satoshis:

Fee: 1000
BSQ wallet outputs:

1. 1200
2. 900

I think the tx might be constructed using only outputs 1. leaving a change output of 200, but it would be possible to construct the tx to take both 1. and 2. to pay the 1000 in fee and get the change 1100.

[ghost]

@sqrrm From what I've seen there is existing code which checks the BSQ for dust before building the transaction (see #3688). The removeDust insertion here looks at the transaction after it is built, just before broadcasting, to remove any dust change BTC. I will look more into how it works though.

[sqrrm]

It's possible the check during tx build is not there but rather later, causing it to look like a bug. Still, that's at least better than burning BSQ unwittingly. If you could check that it's handled properly and not as a bug report that would be best of course.

[ghost]

At the moment there is only one way to get messages back to the GUI - via the errorMessage property on the Offer which is used by numerous exceptional events. I looked into reporting warnings back via adding a warningMessage property and will propose that as a new PR to address #3688. (Its a non-trivial change and I don't want to complicate this PR by adding it in here).

[sqrrm]

ACK