Define a separate trait akin to chain::Listen for notifying when
transactions have been confirmed on chain or unconfirmed during a chain
reorganization. Whereas chain::Listen is used for block-oriented chain
sources, chain::Confirm is used for chain sources supplying data for
activity related to transactions and outputs registered via
chain::Filter.
Previously, if a user simultaneously called
`PeerHandler::process_events()` from two threads, we'd race, which
ended up sending messages out-of-order in the real world.
Specifically, we first called `get_and_clear_pending_msg_events`,
then take the `peers` lock and push the messages we got into the
sending queue. Two threads may both get some set of messages to
send, but then race each other into the `peers` lock and send the
messages in random order.
Because we already hold the `peers` lock when calling most message
handler functions, we can simply take the lock before calling
`get_and_clear_pending_msg_events`, solving the race.
This test failed when ConnectionStyle was set to a SkippingBlocks
variant because of a bug in ChannelMonitor::update_best_block.
Parameterize the test with these styles to catch any regressions.
Define an Electrum-friendly interface for ChannelMonitor where txids of
relevant transactions can be obtained. For any of these transactions
that are re-orged out of the chain, users must call
transaction_unconfirmed.
There is a possible race condition when both the latest block hash and
height are needed. Combine these in one struct and place them behind a
single lock.
When using Electrum, transactions are individually unconfirmed during a
reorg rather than by block. Store the txid of the transaction creating
the on-chain event so that it can be used to determine which events need
to be removed when a transaction is unconfirmed.
Rather than mapping height to a vector of events, use a single vector
for all events. This allows for easily processing events by either
height or transaction. The latter will be used for an interface suitable
for Electrum.
Instead of relying on the user to ensure the funding transaction is
correct (and panicing when it is confirmed), we should check it is
correct when it is generated. By taking the full funding transaciton
from the user on generation, we can also handle broadcasting for
them instead of doing so via an event.
