Add page for BSQ swaps

[chimp1984]

For the upcoming BSQ Swap trade protocol we need a wiki page explaining the background. The links in the app go to : https://bisq.wiki/BSQ_swaps

I add here a general description of the feature. Hope that covers all and serves as base for the content. No need to add all details but I prefer to cover here all so it also can be used a reference for testers,...

A BSQ Swap is a new trade protocol existing in parallel to the default protocol. It is 1 single (atomic) transaction swapping BTC and BSQ inputs and outputs. Therefore it does not require mediation or arbitration support. Either the swap worked or not. Worst case it that an invalid tx got committed to the users wallet and they need to do a SPV-resync, but that should nearly never happen.
There is no fee transaction and no prepared/reserved funds. To ensure that the maker has enough funds when a taker takes the offer we are monitoring the wallet and once the available funds are not sufficient the offer will be disabled (removed from the network). Once the wallet is sufficiently funded again the offer will get re-enabled automatically. This all works without user interaction. The user can see the disable state in the "Open Offer" screen. The offer is then greyed out and a "eye with a strike" icon is shown.

The user still can deactivate the offer like other offers.
Once a taker takes the offer the trade will move to the "BSQ SWAP TRADES" screen in portfolio.
The maker will see a notification on the top right corner (not auto-close) with info that an offer has been taken and a link to the "BSQ SWAP TRADES" screen.

The taker will see a confirmation after confirming the take offer.

When creating or taking an offer the user has similar steps like in normal Bisq trades but removed the fields which are not relevant. There is no fee selection for BSQ/BTC - it is only BSQ used for trade fee.
The miner fee and the trade fee handling is a bit more complicated as we want to avoid unneeded inputs.
E.g. A BTC buyer has only BSQ inputs, so if we would add his share for the miner fee we would require another BTC input. We optimized that so that the miner fee will be deducted from his expected BTC output.
Similar for the BC seller there is only a BTC input including the share of their miner fee and the BSQ trade fee will be deducted from the BSQ outputs.

Here the structure of a tx for a 1 BTC/50 000BSQ trade with 0.5 BSQ maker fee and 1.5 BSQ taker fee and lets estimate buyers miner fee to 2000 sat and sellers miner fee to 2500 sat.
Lets assume the maker is the buyer:

Buyer as makers BSQ input(s): min. 50 000 BSQ + 0.5 BSQ trade fee
Seller as takers BTC input(s): min 1 BTC + 2500 sat - 150 sat (his BSQ trade fee will be used for mining fee, so he needs a bit less miner fee)
Seller as takers BSQ payout output: 50 000 BSQ - 1.5 BSQ trade fee
Buyer as makers BSQ change output: xxx BSQ - optional, can be omitted in case input was exact
Buyer as makers BTC payout output: 1 BTC - 2000 sat miner fee + 50 sat from BSQ fee
Seller as takers BTC change output: xxx BTC - optional, can be omitted in case input was exact

The details for fee adjustment with the BSQ trade fee (which is used as miner fee) can be probably omitted in the documentation as its a minor details and maybe a bit complicated...

Here screenshots from the maker side:

Here screenshots from the taker side:

Completed trade:

As there is no fee tx for the maker we need some offer spam protection and use proof or work for that.
The difficulty (number of leading zeros) is set in the filter. When creating an offer the maker does the pow and attach that data to the offer. Each node verifies the pow and would not show offers with invalid pow.
If the pow increases the offers will re-do their pow in the background and will be republished (old offer removed, new offer with new pow added).

We append a counter to the offer ID at the end (after the version number in the full offer id) each time we re-new the offer by a new pow. That way we have technically a new ID which makes it easier to handle it but for the user it looks like the same ID (short offer ID is same).

The pow will be set to a very low value so users do not recognize anything (in low ms area).
A difficulty of 13 takes about 25 ms on my machine. Each increase is doubling the work, e.g. difficulty 14 requires 50 ms....
I recommend to use a initial value of 7 which is in average below 1 ms. With values about 20 the user will see the delay at offer creation of a few seconds and a spinner animation shows that the app is doing the pow.

Hope I covered everything....