Broaden type requirement

Let Offer handle all OfferPayload data access.

An interface for OfferPayload currently only used by OfferPayload. Some
features won't be available for newer payload types but to fit this into
the Offer and Trade framework it's necessary to hack it a bit.

Offer protobuf has oneof FeeTxOfferPayload and AtomicOfferPayload. This is
backwards compatible since the wire format is the same for the old Offer
and the new one with offer_payload set since the index is the same.

Add a hidden account type that's automatically used for BSQ trades. This
means old orders not using AtomicAccount can still complete the trades
as per normal and new offers placed with AtomicAccount can be taken by
anyone with an upgraded client, but won't be possible to take by users
with older clients.

The atomic account is added on startup if not already added. There is no
data associated with the account, a new BSQ address will be chosen
automatically during the atomic trade process.

Copy paste of normal take offer code with extra steps removed

Added AtomicTxBuilder prototype as a way to build the atomic tx, verify
inputs and gather input requirements. Only the input requirement is used
during the take offer process.

This prepares for letting TradeManager handle AtomicTrade that is a Tradable

Add atomic trade tab under portfolio

Set txid when parsing AtomicTrade from protobuf

- Add offers service protos: GetAtomicOffer, GetMyAtomicOffer,
  GetAtomicOffers, GetMyAtomicOffers, CreateAtomicOffer.

- Add proto message AtomicOfferInfo.

- Add bool tradeAtomic field to CreateCryptoCurrencyPaymentAccountRequest.

- Add trades service protos: GetAtomicTrade, TakeAtomicOffer.

- Add proto message AtomicTradeInfo.

All trade fees are now paid using BSQ for atomic trades. The UI elements
have still not been removed

Clean up some copy paste residue from UI classes

Remove unused AtomicModel

Use bitcoinj version that clones incoming transactions.

This fixes inconsistent wallet problems caused by bisq creating
transactions with outputs going to both the BSQ and BTC wallets.

We need to use capabilities to check if we can send a
msg to the peer containing BSQ_Swap offer data.
Added also support for BundleOfEnvelopes in the
noCapabilityRequiredOrCapabilityIsSupported method and
refactored the method.

The code was never executed as it is not usual that on
one connection multiple messages are sent in a short period.
The handling for bundledEnvelopes has been implemented later
into the broadcast domain, there is does do its job.

Remove generic_string (was not used)

…Builder

As it is about transaction domain I think it fits better in the bitcoin domain

Builder would suggest the builder pattern, so maybe
better use helper.

and AtomicTakerProtocol to BsqSwapTakerProtocol

….atomic.protocol.BsqSwapProtocolModel

Keep bsqSwap and normal trade separate. Leave common classed
in base package.
No good name yet for default trade (default cannot be used as package name)

Cleanups

The package should be enough to qualify them as
BsqSwap tasks. They are only used in the limited scope
of the protocol package.

There is no tx set at bsqSwap place offer protocol

As we are in the offer domain we should use the domain relevant type.

Move Direction one level up and rename to OfferDirection
to match protobuf definition

I think the dependency should be inverted here, so that the
OpenOfferManager does not know about the details about BsqSwap
funding.
Removed FundingListener, use listener on observable list instead
and maintain a filtered list in the BsqSwapWalletWatcher.

Bisq-swap-3

Move TradingPeer to trade package.

Only stub now...

Comment out all existing code in protocol domain. Will get re-added step by step...

- Follow the buyer/seller and maker/taker perspectives
  according to the domain context
- Use the protocol model only for state data required as
  shared model for the tasks
- Add a tradePeer model for holding the peers data
- Keep logic in tasks and use a util class for re-used methods