Expand tests to cover serialization with pending background events

Process monitor update events in block_[dis]connected asynchronously

The instructions for `ChannelManagerReadArgs` indicate that you need
to connect blocks on a newly-deserialized `ChannelManager` in a
separate pass from the newly-deserialized `ChannelMontiors` as the
`ChannelManager` assumes the ability to update the monitors during
block [dis]connected events, saying that users need to:
```
4) Reconnect blocks on your ChannelMonitors
5) Move the ChannelMonitors into your local chain::Watch.
6) Disconnect/connect blocks on the ChannelManager.
```

This is fine for `ChannelManager`'s purpose, but is very awkward
for users. Notably, our new `lightning-block-sync` implemented
on-load reconnection in the most obvious (and performant) way -
connecting the blocks all at once, violating the
`ChannelManagerReadArgs` API.

Luckily, the events in question really don't need to be processed
with the same urgency as most channel monitor updates. The only two
monitor updates which can occur in block_[dis]connected is either
a) in block_connected, we identify a now-confirmed commitment
   transaction, closing one of our channels, or
b) in block_disconnected, the funding transaction is reorganized
   out of the chain, making our channel no longer funded.
In the case of (a), sending a monitor update which broadcasts a
conflicting holder commitment transaction is far from
time-critical, though we should still ensure we do it. In the case
of (b), we should try to broadcast our holder commitment transaction
when we can, but within a few minutes is fine on the scale of
block mining anyway.

Note that in both cases cannot simply move the logic to
ChannelMonitor::block[dis]_connected, as this could result in us
broadcasting a commitment transaction from ChannelMonitor, then
revoking the now-broadcasted state, and only then receiving the
block_[dis]connected event in the ChannelManager.

Thus, we move both events into an internal invent queue and process
them in timer_chan_freshness_every_min().

Change ShutdownResult type to better capture the possibilites

The return value from Channel::force_shutdown previously always
returned a `ChannelMonitorUpdate`, but expected it to only be
applied in the case that it *also* returned a Some for the funding
transaction output.

This is confusing, instead we move the `ChannelMontiorUpdate`
inside the Option, making it hold a tuple instead.

Add a few notes about deserializing stale ChannelManagers

See diff for more details

Fix indentation in test_htlc_no_detection

Move functional tests involving reorgs to reorg_test

functional_tests.rs is huge, so anything we can do to split it up
some is helpful. This also exposes a somewhat glaring lack of
reorgs in our existing tests.

Merge pull request #646 from naumenkogs/2020-06-router-mpp

MPP on the router side

Merge pull request #819 from TheBlueMatt/2021-03-810-rebased

Change ChannelManager deserialization to return an optional blockhash

Merge pull request #818 from jkczyz/2021-03-validate-best-block-header

Add validate_best_block_header utility

Merge pull request #816 from valentinewallace/remove-simple-outer-arcs

Remove simple outer arcs

Don't underpay htlc_min due to path contribution

We could have possibly constructed a slightly inconsistent
path: since we reduce value being transferred all the way, we
could have violated htlc_minimum_msat on some channels
we already passed (assuming dest->source direction). Here,
we recompute the fees again, so that if that's the case, we
match the currently underpaid htlc_minimum_msat with fees.

Update docs to use the new deserialization  requirements

Change ChannelMonitor deserialization to return an optional blockhash.

See previous commit msg for details.

Change ChannelManager deserialization to return an optional blockhash

If the ChannelManager never receives any blocks, it'll return a default blockhash
on deserialization. It's preferable for this to be an Option instead.

Mind htlc_minimum_msat when truncating overpaid value

At truncating the overpaid value, if we fall below
htlc_minimum_msat, reach it by increasing fees.

Use outbound_capacity_msat from first_hops for routing

Implement finding paths for MPP

Add validate_best_block_header utility

Refactor synchronize_listeners by pulling out a function returning the
validated block header of a BlockSource's best chain tip. This is needed
when a node is started from scratch and has no listeners to sync.

Merge pull request #814 from TheBlueMatt/2021-03-optional-handlers

Provide Dummy routing and channel message handlers for users

Merge pull request #813 from jkczyz/2021-02-channel-monitor-mutex

Use interior mutability in ChannelMonitor

Implement chain::Listen without using RefCell

The implementation of chain::Listen for ChannelMonitor required using a
RefCell since its block_connected method required a mutable borrow. This
is no longer the case since ChannelMonitor now uses interior mutability
via a Mutex. So the RefCell is no longer needed.

Change Mutex to RwLock in ChainMonitor

Now that ChannelMonitor uses an internal Mutex to support interior
mutability, ChainMonitor can use a RwLock to manage its ChannelMonitor
map. This allows parallelization of update_channel operations since an
exclusive lock only needs to be held when adding to the map in
watch_channel.

Use consistent variable naming in ChainMonitor

Move ChannelMonitor state behind a Mutex

ChainMonitor accesses a set of ChannelMonitors behind a single Mutex.
As a result, update_channel operations cannot be parallelized. It also
requires using a RefCell around a ChannelMonitor when implementing
chain::Listen.

Moving the Mutex into ChannelMonitor avoids these problems and aligns it
better with other interfaces. Note, however, that get_funding_txo and
get_outputs_to_watch now clone the underlying data rather than returning
references.

Add utility constructors to PeerHandler to use a dummy handler

Provide Dummy routing and channel message handlers for users

We currently "support" not having a router or channel in memory by
forcing users to implement the same, but its trivial to provide our
own dummy implementations.

Merge pull request #811 from TheBlueMatt/2021-02-bindings-rust-bump

Update bindings for new Listen interface

Add simple README about our C bindings generation stuff

[bindings] Build a wasm32-wasi library in genbindings.sh

This will switch to use the clang/C WASM ABI instead of the
wasm_bindgen WASM ABI as of rustc 1.51 (or nightly since [1]),
allowing us to link C and Rust code in a single wasm binary.

[1] https://github.com/rust-lang/rust/pull/79998

Update auto-generated bindings

[bindings] Be explicit when calling trait methods in generated code

For ChannelManager, at least, we have two separate functions called
block_connected, one in the Listen trait, one in the struct, we
need to be explicit with which one we're trying to call.

Fix doc typo introduced in the ChannelKeys->Sign renaming

[bindings] Use global context for secp256k1

Note that this uses https://github.com/rust-bitcoin/rust-secp256k1/pull/279

Merge pull request #802 from TheBlueMatt/2021-01-update-rust-bitcoin

Update rust-bitcoin and add secp256k1 context randomization

Merge pull request #806 from valentinewallace/monitor-data-persistence-path

persist: Persist ChannelMonitors in their own directory.

Rebuild full_stack_target test vector for new secp256k1 fuzz req

Log full signed remote commitment transaction hex in channel

This is useful when rebuilding the full_stack_target test vector

Randomize secp contexts for marginally better sidechannel resistance

Use lowmemory mode for secp256k1 fuzzing, reducing memcpy time

Use rust-secp256k1 PR 282 and bitcoin_hashes PR 111 in fuzzing

SimpleArcPeerManager type: remove outer Arc for flexibility

SimpleArcChannelManager type: remove outer Arc for flexibility

Apply --cfg=fuzzing when fuzzing, as required by new secp256k1

Note that rust-fuzz wrappers (including honggfuzz) already apply
this for us.

Update rust-bitcoin

persist: Persist ChannelMonitors in their own directory.

Merge pull request #791 from jkczyz/2021-01-spv-client

SPV client utility for syncing a lightning node

Utility for syncing a set of chain listeners

Add a utility for syncing a set of chain listeners to a common chain
tip. Required to use before creating an SpvClient when the chain
listener used with the client is actually a set of listeners each of
which may have had left off at a different block. This would occur when
the listeners had been persisted individually at different frequencies
(e.g., a ChainMonitor's individual ChannelMonitors).

Add SpvClient used to poll for the best chain tip

Adds a lightweight client for polling one or more block sources for the
best chain tip. Notifies listeners of blocks connected or disconnected
since the last poll. Useful for keeping a Lightning node in sync with
the chain.

Add ChainNotifier and define ChainListener trait

Add an interface for being notified of block connected and disconnected
events, along with a notifier for generating such events. Used while
polling block sources for a new tip in order to feed these events into
ChannelManager and ChainMonitor.

Add ChainPoller implementation of Poll trait

ChainPoller defines a strategy for polling a single BlockSource. It
handles validating chain data returned from the BlockSource. Thus, other
implementations of Poll must be defined in terms of ChainPoller.

Define a Poll trait as an adaptor on BlockSource

SPV clients need to poll one or more block sources for the best chain
tip and to retrieve related chain data. The Poll trait serves as an
adaptor interface for BlockSource. Implementations may define an
appropriate polling strategy.

Merge pull request #794 from galderz/t_opt_shutdown_anysegwit_780

Add support for `opt_shutdown_anysegwit` feature #780

Add support for `opt_shutdown_anysegwit` feature #780

* Implemented protocol.
* Made feature optional.
* Verify that the default value is true.
* Verify that on shutdown,
if Channel.supports_shutdown_anysegwit is enabled,
the script can be a witness program.
* Added a test that verifies that a scriptpubkey
for an unreleased segwit version is handled successfully.
* Added a test that verifies that
if node has op_shutdown_anysegwit disabled,
a scriptpubkey with an unreleased segwit version on shutdown
throws an error.
* Added peer InitFeatures to handle_shutdown
* Check if shutdown script is valid when given upfront.
* Added a test to verify that an invalid test results in error.
* Added a test to check that if a segwit script with version 0 is provided,
the updated anysegwit check detects it and returns unsupported.
* An empty script is only allowed when sent as upfront shutdown script,
so make sure that check is only done for accept/open_channel situations.
* Instead of reimplementing a variant of is_witness_script,
just call it and verify that the witness version is not 0.

Merge pull request #803 from TheBlueMatt/2021-02-derives

 Standardize trait derives in network message and graph objects

Update auto-generated bindings

Allow cloning NetworkGraphs

Standardize trait derives in network graph objects

In general, trivial structs that have no inner logic can/should
all derive, at least, `Clone, Debug, PartialEq`.

Standardize trait derives in network message objects

In general, trivial structs that have no inner logic can/should
all derive, at least, `Clone, Debug, PartialEq`.

Merge pull request #799 from TheBlueMatt/2021-02-chansigner-rename

Rename ChannelKeys -> Sign and generic it consistently

Further rename `chan_keys` variables to `signers`

Update C++ bindings demo with new struct naming

Update auto-generated bindings

Use ChannelSigner instead of ChanSigner for type parameters

Change Persist's Sign from an associated type to a generic param

Use `signer` instead of `keys_storage` in OnchainTx to hold `Sign`

Rename ChannelKeys -> Sign and generic it consistently

The `ChannelKeys` object really isn't about keys at all anymore,
its all about signing. At the same time, we rename the type aliases
used in traits from both `ChanKeySigner` and `Keys` to just
`Signer` (or, in contexts where Channel isnt clear, `ChanSigner`).

Merge pull request #801 from TheBlueMatt/2021-02-789-bindings

Bindings updates for 789

Merge pull request #752 from valentinewallace/chanman-persistence

ChannelManager persistence

Add BackgroundProcessor for ChannelManager persistence and other

Other includes calling timer_chan_freshness_every_minute() and in the
future, possibly persisting channel graph data.

This struct is suitable for things that need to happen periodically and
can happen in the background.

Add PersistenceNotifier to ChannelManager

This will allow the ChannelManager to signal when it has new
updates to persist, and adds a way for ChannelManager persisters
to be notified when they should re-persist the ChannelManager
to disk/backups.

Feature-gate the wait_timeout function because the core
lightning crate shouldn't depend on wallclock time unless
users opt into it.

Fix Windows persistence

Windows started giving 'Access is denied' errors after
a few rounds of persistence. This seems to fix it.

Abstract out disk-writing utilities from FilesystemPersister

Make logger macros public

These will be used in upcoming commits for the BackgroundProcessor
to log.

Merge pull request #762 from valentinewallace/chan-reserve-fuzz-failure

Don't include below-dust inbound HTLCs in commit tx fee calculation

Update C bindings demos for new KeysManager API

- bindings updates

[bindings] Handle unnamed enum variants

Add a no-bindings-map comment to `std::io::ErrorKind` in DecodeErr

[bindings] Correctly use access string in to-Rust container conv

`from_c_conversion_container_new_var` should use var_access when
it wishes to access the variable being converted, not `var_name`,
but in a few cases it did not. Note that this has no impact on the
generated bindings as of this commit.

- bindings updates

[bindings] Ensure owned objects in Vec conversion are marked `mut`

Switch from slice to slice-of-refs for spend_spendable_outputs

Sadly, there's just not really a practical way to map a slice of
objects in our current bindings infrastructure - either we take
ownership of the underlying objects and move them into a Vec, or we
need to leave the original objects in place and have a list of
pointers to the Rust objects. Thus, the only practical mapping is
to create a slice of references using the pointers we have.

Ensure build_commitment_tx and next_local/remote_tx_fee agree on the fee

Don't include below-dust inbound HTLCs in commit tx fee calculation

Also remove part of the holding cell channel reserve test that's newly failing but
a bit of a redundant test anyway.

Merge pull request #795 from TheBlueMatt/2021-02-features-bindings

Map Features objects in bindings

Merge pull request #789 from TheBlueMatt/2021-02-chansigner-util-fns

Add util fn for creating a Transaction from spendable outputs

Update auto-generated bindings

[bindings] Silence c-bindings-gen compile warnings

[bindings] Handle `impl Clone` like `impl ::core::clone::Clone`

[bindings] Drop manual implementations of Features conversion

We now handle features properly in our own resolution, and these
appear to be self-inconsistent in some cases.

[bindings] Handle generic-ized impl blocks by concretizing them

This handles, for example, the `impl<X: Y> for Features<X>` blocks
which are generic across a number of different contexts. We do so
by walking the set of structs which alias Features and then walking
their generic arguments to check that they meet the bounds
specified in the impl block. For each alias which does, we create
a dummy, explicit, `impl XFeatures` block with the same content as
the original and recurse.

[bindings] Resolve type aliases mapped as opaque types

We already map type aliases which alias private types as opaque,
but we don't resolve them like we would any other opaque type,
preventing conversion printing or type use.

[bindings] Track structs impling traits, incl priv traits

[bindings] Allow resolution of private types in some cases

We need this specifically for resolving the
features::sealed::Context trait which is inside the non-pub
`sealed` module.

Drop a useless import and use `Self` in return values in Features

`Result` is in the standard prelude, so no need to ever use it.

Sadly, returning a Features<T> in the `impl Futures {}` block
will confuse our new alias-impl-printing logic, as we end up
running through the normal impl-block-printing logic as if we had
an explicit `impl ConcreteFeatures` block.

[bindings] Use new ImportResolver during first AST pass

This removes some redundant logic and ensures we handle more
import-resolution cases in both contexts.

[bindings] Track all declared types in ImportResolver construction

This allows an ImportResolver to handle more than imports, allowing
ident resolution of objects constructed in the same module.

[bindings] Extract import resolution logic into a separate struct

This will allow us to reuse the same ident-resolution logic both
during the initial AST pass and during the second conversion pass.

Update demo C++ bindings example for new bindings

Gen bindings with rustc --pretty=expanded instead of reading files

Instead of walking individual rust files and reading the AST from
those, we instead call
`RUSTC_BOOTSTRAP=1 cargo rustc --profile=check -- -Zunstable-options --pretty=expanded`
and let it create one giant lib.rs which we can parse as a whole.
This allows us to parse a post-macro crate, working with structs
and functions created inside macros just fine. It does require
handling a few things that we didn't previously, most notably Clone
via `impl ::core::clone::Clone` blocks instead of just looking for
`#![derive(Clone)]`.

This ends up resolving a few types slightly differently, resulting
in different bindings, but only in ways which don't impact the
runtime.