Expand `ANTI_REORG_DELAY` docs to say its a library-wide assumption

Add an accessor to `ChainMonitor` to get the claimable balances

The common user desire is to get the set of claimable balances for
all non-closed channels. In order to do so, they really want to
just ask their `ChainMonitor` for the set of balances, which they
can do here by passing the `ChannelManager::list_channels` output
to `ChainMonitor::get_claimable_balances`.

Expose the amount of funds available for claim in ChannelMonitor

In general, we should always allow users to query for how much is
currently in-flight being claimed on-chain at any time.

This does so by examining the confirmed claims on-chain and
breaking down what is left to be claimed into a new
`ClaimableBalance` enum.

Fixes #995.

Fix indentation in ChannelMonitor

Track how our HTLCs are resolved on-chain persistently

This tracks how any HTLC outputs in broadcast commitment
transactions are resolved on-chain, storing the result of the HTLC
resolution persistently in the ChannelMonitor.

This can be used to determine which outputs may still be available
for claiming on-chain.

Track the tx which spends our funding output in ChannelMonitor

This allows us to easily look up how our channel was closed and
track which balances may be spendable on-chain.

Rename CounterpartyCommitmentTransaction to Params as it is static

Drop unused CounterpartyCommitmentTransaction::per_htlc HashMap

Store to-self value in the current commitment tx in ChannelMonitor

Remove DynamicOutputP2WPKH ref in logger

Don't initialise Vecs being read with VecReadWrapper explicitly

This simplifies the tlv serialization read macro somewhat by
allowing callsites to simply read into an `Option<Vec>` instead of
needing to read into an `Option<VecReadWrapper>` when using
`vec_type`.

Merge pull request #1051 from JosephGoulden/fix_ping_disconnect

fix: peer is disconnected for not responding to ping

test: increase ping timeout when running in debug mode

Merge pull request #1049 from TheBlueMatt/2021-08-nightly-warnings

Fix trailing semicolon warnings on latest rustc nightly

Fix trailing semicolon warnings on latest rustc nightly

Latest rustc nightly compiles are filled with warnings like the
following, which we fix here:

```
warning: trailing semicolon in macro used in expression position
   --> lightning/src/util/macro_logger.rs:163:114
    |
163 |         $logger.log(&$crate::util::logger::Record::new($lvl, format_args!($($arg)+), module_path!(), file!(), line!()));
    |                                                                                                                        ^
    |
   ::: lightning/src/chain/chainmonitor.rs:165:9
    |
165 |         log_debug!(self.logger, "New best block {} at height {} provided via block_connected", header.block_hash(), height);
    |         -------------------------------------------------------------------------------------------------------------------- in this macro invocation
    |
    = note: `#[warn(semicolon_in_expressions_from_macros)]` on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `log_internal` (in Nightly builds, run with -Z macro-backtrace for more info)
```

Merge pull request #1048 from TheBlueMatt/2021-08-no-net-print

Remove explicit print in lightning-net-tokio, reduce redundant block connection logging

Clarify docs on ShutdownScript::new_witness_program somewhat

This is especially important for C or other language bindings
clients as the `version` field may be exported as a `u8`.

Log chain calls in ChainMonitor, reducing logs in ChannelMonitor

For users with many ChannelMonitors, we log a large volume per
block simply because each ChannelMonitor lots several times per
block. Instead, we move to log only once at the TRACE level per
block call in ChannelMonitors, relying instead on a DEBUG level
log in ChainMonitor before we call any ChannelMonitor functions.

For most users, this will reduce redundant logging and also log at
the DEBUG level for block events, which is appropriate.

Fixes #980.

Stop printing to stderr in lightning-net-tokio for disconnections

It isn't exactly a critical error situation when we disconnect a
socket, so we shouldn't be printing to stderr, entirely bypassing
user logging, when it happens. We do still print to stderr if we
fail to write the first message to the socket, but this should
never happen unless the user has a reasonably-configured system
with at least one packet in bytes available for the socket buffer.

Ensure we always at least log at TRACE when a peer disconnects

Merge pull request #1044 from TheBlueMatt/0.0.100

Cut 0.0.100

Update versions to 0.0.100 and lightning-invoice to 0.8

Update CHANGELOG for 0.0.100

Merge pull request #1011 from TheBlueMatt/2021-07-new-closing-fee

Clean up existing and add range-based closing_signed negotiation

Add relatively simple tests of the legacy and target closing fee

This doesn't exhaustively test closing fee negotiation at all, but
ensures that it is at least basically able to come to consensus and
sign cooperative closing transactions.

Slightly clarify the closing_signed error msg on fee mismatch

Add a test for shutdown negotiaion funder restart and timeout

Force-close if finish closing_signed negotiation takes a full minute

Move shutdown-related tests into a new module

Because ln::functional_tests if over 9000 LoC long, its useful to
move tests into new modules as we can. Here we move all
cooperative shutdown related tests into a new module entitled
`shutdown_tests`

Clean up existing and add range-based closing_signed negotiation

This adds the new range-based closing_signed negotiation specified
in https://github.com/lightningnetwork/lightning-rfc/pull/847 as
well as cleans up the existing closing_signed negotiation to unify
the new codepaths and the old ones.

Note that because the new range-based closing_signed negotiation
allows the channel fundee to ultimately select the fee out of a
range specified by the funder, which we, of course, always select
the highest allowed amount from. Thus, we've added an extra round
of closing_signed in the common case as we will not simply accept
the first fee we see, always preferring to make the funder pay as
much as they're willing to.

Send initial closing_signed message asynchronously and handle errs

When we added the support for external signing, many of the
signing functions were allowed to return an error, closing the
channel in such a case. `sign_closing_transaction` is one such
function which can now return an error, except instead of handling
it properly we'd simply never send a `closing_signed` message,
hanging the channel until users intervene and force-close it.

Piping the channel-closing error back through the various callsites
(several of which already have pending results by the time they
call `maybe_propose_first_closing_signed`) may be rather
complicated, so instead we simply attempt to propose the initial
`closing_signed` in `get_and_clear_pending_msg_events` like we do
for holding-cell freeing.

Further, since we now (possibly) generate a `ChannelMonitorUpdate`
on `shutdown`, we may need to wait for monitor updating to complete
before we can send a `closing_signed`, meaning we need to handle
the send asynchronously anyway.

This simplifies a few function interfaces and has no impact on
behavior, aside from a few message-ordering edge-cases, as seen in
the two small test changes required.

Merge pull request #1045 from TheBlueMatt/2021-08-chanmon-ser-upgradability

Make `ChannelMonitor` serialization slightly more upgradable

Migrate OnchainEvent serialization to be MaybeReadable.

This adds a new TLV-based enum serialization macro entitled
`impl_writeable_tlv_based_enum_upgradable`. As the name implies,
the new macro allows us to ignore odd-numbered variant entries.
Because the new macro implements only `MaybeReadable` and not
`Readable`, it is not applicable in many contexts, here only being
added for the two `OnchainEvent` structs.

Implement `VecReadWrapper` for `MaybeReadable`

This makes it much simpler to deal with `MaybeReadable` types in
`Vec`s in TLVs as we can transparently deal with them as `vec`,
with the wrapper doing the Right Thing.

This requires we implement `MaybeReadable` for all `Readable` which
has some downstream implications, but nothing too bad.

Do not serialize `Channel::last_sent_closing_fee` to disk

We're supposed to write `Channel` to disk as if
`remove_uncommitted_htlcs_and_mark_paused` had just run, however we
were writing `last_sent_closing_fee` to disk (if it is not-None),
whereas `remove_uncommitted_htlcs_and_mark_paused` clears it.
Indeed, the BOLTs say fee "... negotiation restarts on
reconnection."

Log shutdown including which side of the channel initiated shutdown

Implement the closing_signed TLV suffix with allowed fee ranges

This adds the serialization and structures for the new fee range
specifiers in closing_signed as added upstream at
https://github.com/lightningnetwork/lightning-rfc/pull/847

Improve TLV serialization macro callability very slightly

This allows decode_tlv_stream!() to be called with either a mutable
reference to a stream or a stream itself and allows
encode_tlv_stream!() to be called with an excess , at the end of
the parameter list.

Add new `ChannelError` category to send `warning` messages

We don't actually yet support `warning` messages as there are
issues left to resolve in the spec PR, but there's nothing to stop
us adding an internal enum variant for sending a warning message
before we actually support doing so.

Add #[allow(unused_mut)] on reorg_test as older rustc requires mut

Merge pull request #985 from TheBlueMatt/2021-06-auto-chan-fee-updates

Automatically Update fees on outbound channels

Limit inbound fee updates by dust exposure instead of our estimator

Inbound fee udpates are rather broken in lightning as they can
impact the non-fundee despite the funder paying the fee, but only
in the dust exposure it places on the fundee.

At least lnd is fairly aggressively high in their (non-anchor) fee
estimation, running the risk of force-closure. Further, because we
relied on a fee estimator we don't have full control over, we
were assuming our users' fees are particularly conservative, and
thus were at a lot of risk to force-closures.

This converts our fee limiting to use an absurd upper bound,
focusing on whether we are over-exposed to in-flight dust when we
receive an update_fee.

Log when we change HTLC state while sending a commitment transaction

Fix handling of inbound uncommitted feerate updates

If we receive an update_fee but do not receive a commitment_signed,
we should not persist the pending fee update to disk or hold on to
it after our peer disconnects.

In order to make the code the most readable, we add a state enum
which matches the relevant states from InboundHTLCState, allowing
for more simple code comparison between inbound HTLC handling and
update_fee handling.

Fix re-sending commitment updates with an outbound fee update

When we send an update_fee to our counterparty on an outbound
channel, if we need to re-send a commitment update after
reconnection, the update_fee must be present in the re-sent
commitment update messages. However, wewere always setting the
update_fee field in the commitment update to None, causing us to
generate invalid commitment signatures and get channel
force-closures.

This fixes the issue by correctly detecting when an update_fee
needs to be re-sent, doing so when required.

Add more logging during chanmon_consistency runs

Add fuzz coverage of (potential) fee update messages

Automatically update fees on outbound channels as fees change

Previously we'd been expecting to implement anchor outputs before
shipping 0.1, thus reworking our channel fee update process
entirely and leaving it as a future task. However, due to the
difficulty of working with on-chain anchor pools, we are now likely
to ship 0.1 without requiring anchor outputs.

In either case, there isn't a lot of reason to require that users
call an explicit "prevailing feerates have changed" function now
that we have a timer method which is called regularly. Further, we
really should be the ones deciding on the channel feerate in terms
of the users' FeeEstimator, instead of requiring users implement a
second fee-providing interface by calling an update_fee method.

Finally, there is no reason for an update_fee method to be
channel-specific, as we should be updating all (outbound) channel
fees at once.

Thus, we move the update_fee handling to the background, calling it
on the regular 1-minute timer. We also update the regular 1-minute
timer to fire on startup as well as every minute to ensure we get
fee updates even on mobile clients that are rarely, if ever, open
for more than one minute.

Set cfg=fuzzing when building fuzz crate in CI

We will likely drop the fuzztarget feature soon, and should thus be
setting cfg=fuzzing explicitly anyway.

Add standard derives for ConfirmationTarget

Merge pull request #1009 from ariard/2021-07-add-forward-dust-limit

Add new config setting `max_balance_dust_htlc_msat`

Add test_max_balance_dust_htlc

Enforce `max_balance_dust_htlc_msat` at HTLC reception/forward

At `update_add_htlc()`/`send_htlc()`, we verify that the inbound/
outbound dust or the sum of both, on either sides of the link isn't
above new config setting `max_balance_dust_htlc_msat`.

A dust HTLC is hence defined as a trimmed-to-dust one, i.e including
the fee cost to publish its claiming transaction.

Modify pending inbound/outbound getters to access dust balances

Add new config setting `max_balance_dust_htlc_msat`

Trimmed-to-dust HTLCs are at risk of being burnt as miner fees
at anytime during their lifetime due to the broadcast of either
holder commitment transaction or counterparty's one.

To hedge against this risk, we introduce a new config setting
`max_balance_dust_htlc_msat`, with the initial value of
5_000_000 msat.

Merge pull request #1025 from TheBlueMatt/2021-07-detect-htlcs-on-local-commitment

Merge pull request #1038 from valentinewallace/2021-08-keysend-docs

Add requirement of payment secret for multi path payments

in send_payment_internal

Merge pull request #1019 from jkczyz/2021-07-shutdown-pubkey

Fetch shutdown script based on `commit_upfront_shutdown_pubkey`

Add APIError::IncompatibleShutdownScript

Implement Display for ShutdownScript

Pass InitFeatures by reference to Channel

Remove unreachable BroadcastChannelUpdate

When handling shutdown messages, Channel cannot move to
ChannelState::ShutdownComplete. Remove the code in ChannelManager that
adds a MessageSendEvent::BroadcastChannelUpdate in this case since it is
unreachable.

Generate shutdown script at channel close

When a shutdown script is omitted from open_channel or accept_channel,
it must be provided when sending shutdown. Generate the shutdown script
at channel closing time in this case rather at channel opening.

This requires producing a ChannelMonitorUpdate with the shutdown script
since it is no longer known at ChannelMonitor creation.

Add features to NodeCfg and use in create_network

Connect nodes in remaining tests

Similar to 2745bd5ac776c48950bcb630338538d31a9615d0, this ensures that
ChannelManager knows about the features its peers.

Support all shutdown scripts defined in BOLT 2

KeysInterface::get_shutdown_pubkey is used to form P2WPKH shutdown
scripts. However, BOLT 2 allows for a wider variety of scripts. Refactor
KeysInterface to allow any supported script while still maintaining
serialization backwards compatibility with P2WPKH script pubkeys stored
simply as the PublicKey.

Add an optional TLV field to Channel and ChannelMonitor to support the
new format, but continue to serialize the legacy PublicKey format.

Use ShutdownScript to check scripts from peers

Add ShutdownScript for BOLT 2 acceptable scripts

BOLT 2 enumerates the script formats that may be used for a shutdown
script. KeysInterface::get_shutdown_pubkey returns a PublicKey used to
form one of the acceptable formats (P2WPKH). Add a ShutdownScript
abstraction to encapsulate all accept formats and be backwards
compatible with P2WPKH scripts serialized as the corresponding
PublicKey.

Clean up and add shutdown script functional tests

Merge pull request #1035 from TheBlueMatt/2021-08-faster-pings

Suggest faster ping in `PeerManager::timer_tick_occurred` docs

Handle being asleep for more than double our ping time gracefully

If we've been asleep for double our ping time, for whatever reason,
disconnect all open sockets.

Update lightning-background-processor to ping every five seconds

This updates lightning-background-processor calls to
PeerManager::timer_tick_occurred to match the new suggested rate in
the documentation.

Suggest faster ping in `PeerManager::timer_tick_occurred` docs

This clarifies the docs for `PeerManager::timer_tick_occurred` to
note that the call rate is entirely up to the user, and also
suggests a faster ping rate of "once every five to ten seconds"
instead of "every 30 seconds". There isn't a lot of reason to want
to ping less often, and faster ping means we detect disconnects
sooner, which is important.

Correctly detect missing HTLCs when a local commitment tx was broadcast

If we forward an HTLC to our counterparty, but we force-closed the
channel before our counterparty provides us an updated commitment
transaction, we'll end up with a commitment transaction that does
not contain the HTLC which we attempted to forward. In this case,
we need to wait `ANTI_REORG_DELAY` blocks and then fail back the
HTLC as there is no way for us to learn the preimage and the
confirmed commitment transaction paid us the value of the HTLC.

However, check_spend_holder_transaction did not do this - it
instead only looked for dust HTLCs in the confirmed commitment
transaction, paying no attention to what other HTLCs may exist that
are missed.

This will eventually lead to channel force-closure as the channel
on which we received the inbound HTLC to forward will be closed in
time for the initial sender to claim the HTLC on-chain.

DRY HTLC failure code in check_spend_counterparty_transaction

This extracts the HTLC-not-in-broadcasted-commitment-transaction
code from check_spend_counterparty_transaction and moves it to a
global macro, DRYing up the two very similar codepaths (fixing
some minor logging inconsistencies) in the process.

This macro will be used for local commitment transaction HTLC
failure as well in the next commit.

This commit has no functional change outside of logging.

Update keysend docs

Merge pull request #1029 from TheBlueMatt/2021-07-log-channel-close

Log when a channel is closed on startup due to stale ChannelManager

Make BackgroundProcessor `#[must_use]` to avoid dropping immediately

It is easy for users to have a bug where they drop a
`BackgroundProcessor` immediately, causing it to start and then
immediately stop. Instead, add a `#[must_use]` tag to provide a
compiler warning for such instances.

Log when a channel is closed on startup due to stale ChannelManager

This is one of the riskiest parts of our API from the perspective
of accidental force-closes - if users delay persisting the
ChannelManager much at all after a ChannelMonitor we may hit a
force-close after restart.

The fact that we don't log at all when this happens is criminal.

Add additional TLV serialization type of (default_value, N)

This allows TLV serialization macros to read non-Option-wrapped
types but allow them to be missing, filling them in with the
provided default value as needed.

Merge pull request #1004 from TheBlueMatt/2021-07-forward-event

Add a `PaymentForwarded` Event

Change return value of `claim_funds` to ignore duplicate claims

While we should never reach `ClaimFundsFromHop::DuplicateClaim` in
most cases, if we do, it likely indicates the HTLC was timed out
some time ago and is no longer available to be claimed. Thus, it
does not make sense to imply that we `claimed_any_htlcs`.

Generate a PaymentForwarded event when a forwarded HTLC is claimed

It is useful for accounting and informational reasons for users to
be informed when a payment has been successfully forwarded. Thus,
when an HTLC which represents a forwarded leg is claimed, we
generate a new `PaymentForwarded` event.

This requires some additional plumbing to return HTLC values from
`OnchainEvent`s. Further, when we have to go on-chain to claim the
inbound side of the payment, we do not inform the user of the fee
reward, as we cannot calculate it until we see what is confirmed
on-chain.

Substantial code structure rewrites by:
Valentine Wallace <vwallace@protonmail.com>

Merge pull request #1022 from TheBlueMatt/2021-07-to-remote-reorg

Fix to_remote SpendableOutputs generation in rare reorg cases

Fix to_remote SpendableOutputs generation in rare reorg cases

If we first see a local commitment transaction, and then a reorg
causes the confirmed channel close transaction to instead be a
remote commitment transaction, we would fail a spurious `if else`
check, resulting in us not generating the correct `SpendableOutput`
event for the to_remote output now confirmed on chain.

This resolves the incorrect logic and adds a regression test.

Merge pull request #1028 from lightning-signer/2021-08-no-std

Actual no_std support

Rename no_std feature to no-std

matches rust-bitcoin

Merge pull request #1033 from TheBlueMatt/2021-07-fix-beta

Fix lightning-persister tests for upcoming rustc changes

Actual no_std support

Check IO errors in test using `raw_os_error()` instead of `kind()`

std::io::ErrorKind is a `#[non_exhaustive]` enum as more specific
error types are to be added in the future. It was unclear in the
docs until very recently, however, that this is to be done by
re-defining `ErrorKind::Other` errors to new enum variants. Thus,
our tests which check explicitly for `ErrorKind::Other` as a
result of trying to access a directory as a file were incorrect.
Sadly, these generated no meaningful feedback from rustc at all,
except that they're suddenly failing in rustc beta!

After some back-and-forth, it seems rustc is moving forward
breaking existing code in future versions, so we move to the
"correct" check here, which is to check the raw IO error.

See rust-lang/rust#86442 and rust-lang/rust#85746 for more info.

Merge pull request #1032 from jkczyz/2021-08-clippy

Fail linter on #[warn(clippy::try_err)]

Some heavily used macros are using ? directly on an Err. Using a return
is easier to read and removes hundreds of linter warnings.

https://rust-lang.github.io/rust-clippy/master/index.html#try_err

Fix #[warn(clippy::try_err)] in ser_macros.rs

Add CI runs on rustc beta on Windows and MacOS

This should catch any platform-specific behavior changes in rustc
before they land in stable.

Merge pull request #1012 from TheBlueMatt/2021-07-bump-deps

Bump dependencies to bitcoin 0.27 and bech32 0.8

Add a `#[macro_use]` on the `alloc` import for `format!()`

Fix no_std warnings due to unused includes

Drop MSRV for no_std to 1.47 as that's what Ubuntu LTS ships with

...but disable it for now given core2 is broken (it claims an MSRV
of 1.47 but does not build).

Bump dependencies to bitcoin 0.27 and bech32 0.8