This introduces a lot of duplication between the binary and the
library, but it's okay because this module should only be a temporary
measure until we allow recovery to be handled by the original state
machine.
Also, fix a bug in `xmr_btc::alice::action_generator` caused by the
incorrect assumption that Alice's ability to punish Bob could be
determined before the cancel transaction hits the blockchain.
The numerous tor conditional compile flags were removed by
extracting transport creation to the main statement. A tor
transport is created if Alice specifies a tor port using the CLI.
The hardcoded configuration was replaced with CLI
configuration options. CLI based config was chosen
over a config file as it does not access and clutter
the user's file system. By CLI options depend on whether
the program is run in Alice or Bob mode.
Before this patch Bob is not sending message 3. This is because we are not
polling Bob's swarm correctly. To fix it we can just mimic the other NB's and
bubble up an event when Bob receives message 3 response from Alice, this way we
can `await` upon this event which triggers polling, making Bob's swarm send the
message.
Also use cosntant backoff retry strategy as opposed to exponential
backoff. This is in case retrying several times quickly causes the
retry intervals to become large enough that the test is very slow
and/or the Bitcoin lock transaction expires.
The current problem occurs on the last message i.e. Bob sending
tx_redeem_encsig to Alice. The action is yielded for Bob to do it, but
Alice appears to never receive it (unconfirmed claim, requires more
logging).
Unfortunately, I had to put the wrap the swarm in Alice's `Network`
struct in an `Arc<Mutex<T>>` in order to be able to use `backoff` to
control the retry mechanism. This is because the stream of events
cannot be turned into a `SharedFuture` (unlike Bob's).
It would be good to find an alternative solution.