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>

Test preimages are learned instantly in test_onchain_to_onchain_claim

test_onchain_to_onchain_claim was connecting additional blocks in
order to reach HTLC timeout and broadcast an HTLC-Timeout
transaction, resulting in it not testing whether HTLC preimages are
learned instantly in response to HTLC-Success transactions.

Ignore unknown Events serialized with an odd type value.

This should provide some additional future extensibility, allowing
for new informational events which can be safely ignored to be
ignored by older versions.

Drop single-use macro from check_spend_holder_transaction

The wait_threshold_conf!() macro in check_spend_holder_transaction
was only used once, making it a good candidate for inlining at the
callsite. Further, it incorrectly always logged that we were
failing HTLCs from the "latest" commitment transaction, when it is
sometimes actually failing HTLCs from the previous commitment
transaction.

Merge pull request #977 from TheBlueMatt/2021-06-fix-double-claim-close

Handle double-HTLC-claims without failing the backwards channel

Fail channel if we can't sign a new commitment tx during HTLC claim

Previously, we could fail to generate a new commitment transaction
but it simply indicated we had gone to doule-claim an HTLC. Now
that double-claims are returned instead as Ok(None), we should
handle the error case and fail the channel, as the only way to hit
the error case is if key derivation failed or the user refused to
sign the new commitment transaction.

This also resolves an issue where we wouldn't inform our
ChannelMonitor of the new payment preimage in case we failed to
fetch a signature for the new commitment transaction.

Simplify call graph of get_update_fulfill_htlc since it can't Err.

Handle double-HTLC-claims without failing the backwards channel

When receiving an update_fulfill_htlc message, we immediately
forward the claim backwards along the payment path before waiting
for a full commitment_signed dance. This is great, but can cause
duplicative claims if a node sends an update_fulfill_htlc message,
disconnects, reconnects, and then has to re-send its
update_fulfill_htlc message again.

While there was code to handle this, it treated it as a channel
error on the inbound channel, which is incorrect - this is an
expected, albeit incredibly rare, condition. Instead, we handle
these double-claims correctly, simply ignoring them.

With debug_assertions enabled, we also check that the previous
close of the same HTLC was a fulfill, and that we are not moving
from a HTLC failure to an HTLC claim after its too late.

A test is also added, which hits all three failure cases in
`Channel::get_update_fulfill_htlc`.

Found by the chanmon_consistency fuzzer.

Merge pull request #967 from valentinewallace/2021-06-keysend

Keysend

Clarify decode_update_add_htlc_onion comment

Clearer phrasing

tests: make PaymentSecret optional in pass_along path

and use it to make more keysend tests

Implement utilities for keysending to private nodes

Implement sending keysend payments (to public nodes)

test utils: add optional PaymentPreimage param to pass_along_path

This will allow keysend tests to assert that the PaymentReceived payment preimage is
as expected in upcoming commits.

Implement receiving keysend payments

Refactor PaymentReceived event for keysend receives

Add PendingHTLCRouting variant for receiving keysend payments

Fix indentation in decode_update_add_htlc_onion

Advertise keysend feature

C-Lightning requires us to advertise this feature before they'll
attempt a keysend payment to us.

Parse keysend TLV field in onion.

This doesn't yet use the field, but it will be used in upcoming commits.

Merge pull request #998 from TheBlueMatt/2021-07-fix-chan-reserve-msat-sat

Fix channel reserve calculation on the sending side

Merge pull request #986 from TheBlueMatt/2021-07-route-lasthop-value

[router] Use the invoice value for last-hop hint channel capacity

Merge pull request #1008 from lightning-signer/2021-07-sync-no-std

Dummy sync implementation for no_std

Merge pull request #1010 from sr-gi/enforce_signature_length

Test no_std instead of just hashbrown

Implement dummy Mutex, Condvar and RwLock

Enforces sig_rec length in message_signing

Collect all lightning std::sync imports under crate::sync

in preparation for no-std sync dummies

Merge pull request #1003 from jkczyz/2021-known-features-mask

Expand tests for Features::to_context

Merge pull request #1002 from valentinewallace/2021-07-fix-features-index-bounds

Test index-out-of-bounds in Features::to_context

When there are fewer known `from` feature bytes than known `to` feature
bytes, an index-out-of-bounds error can occur if the `from` features
have unknown features set in a byte past the greatest known `from`
feature byte.

Remove unnecessary feature test-only methods

Fix crash due to index-out-of-bounds in feature translation

This was reported by a user when trying to send a payment using the LDK
sample (specifically during route generation when translating a Features
from one context to another)

The problem was we didn't check T::KNOWN_FEATURE_MASK vec length before
indexing into it, due likely to the assumption that known feature vec
lengths are the same across contexts, when they may not be

Support pending update_fail_htlcs in reconnect_nodes test util

Fix channel reserve calculation on the sending side

As the variable name implies holder_selected_chan_reserve_msat is
intended to be in millisatoshis, but is instead calculated in
satoshis.

We fix that error here and update the relevant tests to more
accurately calculate the expected reserve value and test both
success and failure cases.

Bug discovered by chanmon_consistency fuzz target.

Merge pull request #990 from TheBlueMatt/2021-07-0.0.99

Cut 0.0.99

Bump most crate versions to 0.0.99 and lightning-invoice to 0.7.0

Add documentation for all PRs slated to land for 0.0.99

Merge pull request #975 from TheBlueMatt/2021-06-fix-fee-calc

Make the base fee configurable in ChannelConfig

Change serialization backwards compat in Channel to use new version

Instead of interpreting the backwards compatibility data in Channel
serialization, use the serialization version bump present in 0.0.99
as the flag to indicate if a channel should be read in backwards
compatibility.

Add a note clarifying the API guarantees of create_channel

Optionally reject HTLC forwards over priv chans with a new config

Private nodes should never wish to forward HTLCs at all, which we
support here by disabling forwards out over private channels by
default. As private nodes should not have any public channels, this
suffices, without allowing users to disable forwarding over
channels announced in the routing graph already.

Closes #969

Update full_stack_target demo input to match new, fewer, fee gets

Make the base fee configurable in ChannelConfig

Currently the base fee we apply is always the expected cost to
claim an HTLC on-chain in case of closure. This results in
significantly higher than market rate fees [1], and doesn't really
match the actual forwarding trust model anyway - as long as
channel counterparties are honest, our HTLCs shouldn't end up
on-chain no matter what the HTLC sender/recipient do.

While some users may wish to use a feerate that implies they will
not lose funds even if they go to chain (assuming no flood-and-loot
style attacks), they should do so by calculating fees themselves;
since they're already charging well above market-rate,
over-estimating some won't have a large impact.

Worse, we current re-calculate fees at forward-time, not based on
the fee we set in the channel_update. This means that the fees
others expect to pay us (and which they calculate their route based
on), is not what we actually want to charge, and that any attempt
to forward through us is inherently race-y.

This commit adds a configuration knob to set the base fee
explicitly, defaulting to 1 sat, which appears to be market-rate
today.

[1] Note that due to an msat-vs-sat bug we currently actually
    charge 1000x *less* than the calculated cost.

Update ChannelConfig serialization to be TLV-based

This was missed prior to 0.0.98, so requires a
backwards-compatibility wrapper inside the `Channel` serialization
logic, but it's not very complicated to do so.

Merge pull request #988 from TheBlueMatt/2021-07-chan-details-usability

Improve ChannelDetails readability significantly.

Improve ChannelDetails readability significantly.

After the merge of #984, Jeff pointed out that `ChannelDetails` has
become a bit of a "bag of variables", and that a few of the variable
names in #984 were more confusing than necessary in context.

This addresses several issues by:
 * Splitting counterparty parameters into a separate
   `ChannelCounterpartyParameters` struct,
 * using the name `unspendable_punishment_reserve` for both outbound
   and inbound channel reserves, differentiating them based on their
   position in the counterparty parameters struct or not,
 * Using the name `force_close_spend_delay` instead of
   `spend_csv_on_our_commitment_funds` to better communicate what
   is occurring.

Merge pull request #961 from TheBlueMatt/2021-06-workaround-broken-cln

Use the query start block for ReplyChannelRange response messages

Use the query start block for ReplyChannelRange response messages

C-Lightning versions prior to 0.10 (incorrectly) enforce that the
reply_channel_range first_blocknum field is set to at least the
value they sent in their query_channel_range message. Sending a 0
results in them responding with an Error message, closing open
channels spuriously.

Further, C-Lightning versions prior to 0.10 require that the
reply_channel_range first_blocknum is either the same block implied
as the last block of the previous reply_channel_range or one
greater. This is not only a creative interpretation of the spec,
but a perfectly reasonable implementation might still receive an
Error message in the case of replies split by an empty block.

This code is extracted and modified from a previous version of
the original query_channel_range PR in commit
44ba52ccf10bb0362ed2964b66ec2ae51e388161. The original commit is by
`bmancini55 <bmancini@gmail.com>`.

Merge pull request #949 from TheBlueMatt/2021-06-send-priv-update

Send channel_update messages to direct peers on private channels

Ignore our own gossip if it is sent to us from our counterparty

If our channel party sends us our own channel_update message, we'll
erroneously use the information in that message to update our view
of the forwarding parameters our counterparty requires of us,
ultimately generating invoices with bogus forwarding information.

This fixes that behavior by checking the channel_update's
directionality before handling it.

Fix spelling in ChannelManager comment

Send channel_update messages to direct peers on private channels

If we are a public node and have a private channel, our
counterparty needs to know the fees which we will charge to forward
payments to them. Without sending them a channel_update, they have
no way to learn that information, resulting in the channel being
effectively useless for outbound-from-us payments.

This commit fixes our lack of channel_update messages to private
channel counterparties, ensuring we always send them a
channel_update after the channel funding is confirmed.

Merge pull request #984 from TheBlueMatt/2021-06-more-chan-data

Expose More Information about Channels and structs

Tweak documentation in `BestBlock` to be a bit more clear

Expose the current best chain tip from ChannelManager + Monitors

Fixes #979

Expand the fields exposed to users in `ChannelDetails`

This adds four new fields in `ChannelDetails`:
1. holder_selected_ and counterparty_selected_channel_reserve_delay
   are useful to determine what amount of the channel is
   unavailable for payments.
2. confirmations_required is useful when awaiting funding
   confirmation to determine how long you will need to wait.
3. to_self_delay is useful to determine how long it will take to
   receive funds after a force-close.

Fixes #983.

Drop Channel HTLC transaction building thin wrapper function

Make channel fields which are from accept_channel Optional

These fields are set with a dummy value, which we should generally
be avoiding since Rust gives us a nice `Option` type to use
instead.

Further, we stop rejecting channel_update messages outright when
the htlc_maximum_msat field includes the reserve values, which
nodes could reasonably do without it meriting a channel closure.

[router] Use the invoice value for last-hop hint channel capacity

If an invoice contains route hints, we should assume the channel
capacity is sufficient to route the invoice's value.

Merge pull request #958 from TheBlueMatt/2021-06-fix-router-panic

Fix panic in router given to bogus last-hop hints

Fix panic in router given to bogus last-hop hints

See new comments and test cases for more info

Reject minimum_depth of 0 on channel opens

We don't support turbo channels so this is a pretty clear
indication that there is some incompatibility.

Never generate a `BroadcastChannelUpdate` for priv channels

Currently we always generate a
`MessageSendEvent::BroadcastChannelUpdate` when a channel is closed
even if the channel is private. Our immediate peers should ignore
such messages as they haven't seen a corresponding
`channel_announcement`, but we are still giving up some privacy by
informing our immediate peers of which channels were ours.

Here we split `ChannelManager::get_channel_update` into a
`get_channel_update_for_broadcast` and
`get_channel_update_for_unicast`. The first is used when we are
broadcasting a `channel_update`, allowing us to refuse to do so
for private channels. The second is used when failing a payment (in
which case the recipient has already shown that they are aware of
the channel so no such privacy concerns exist).

Merge pull request #970 from TheBlueMatt/2021-06-no-confirmed-csv-delay

Create SpendableOutputs events no matter the chain::Confirm order

Clean up get_broadcasted_holder_claims confirmation height param use

Clarify when height is the *current* vs a *confirmation* height

Create SpendableOutputs events no matter the chain::Confirm order

We had a user who pointed out that we weren't creating
`SpendableOutputs` events when we should have been after they
called `ChannelMonitor::best_block_updated` with a block well
after a CSV locktime and then called
`ChannelMonitor::transactions_confirmed` with the transaction which
we should have been spending (with a block height/hash a ways in
the past).

This was due to `ChannelMonitor::transactions_confirmed` only
calling `ChannelMonitor::block_confirmed` with the height at which
the transactions were confirmed, resulting in all checks being done
against that, not the current height.

Further, in the same scenario, we also would not fail-back and HTLC
where the HTLC-Timeout transaction was confirmed more than
ANTI_REORG_DELAY blocks ago.

To address this, we use the best block height for confirmation
threshold checks in `ChannelMonitor::block_confirmed` and pass both
the confirmation and current heights through to
`OnchainTx::update_claims_view`, using each as appropriate.

Fixes #962.

Update `ChannelMonitor::best_block` before calling block_confirmed

No matter the context, if we're told about a block which is
guaranteed by our API semantics to be on the best chain, and it has
a higher height than our current understanding of the best chain,
we should update our understanding. This avoids complexity
in `block_confirmed` by never having a height set which is *higher*
than our current best chain, potentially avoiding some bugs in the
rather-complicated code.

It also requires a minor test tweak as we in some cases now no
longer broadcast a conflicting transaction after the original has
reached the ANTI_REORG_DELAY.

Avoid calling OnchainTx::block_disconnected if no block was discon'd

There are no visible effects of this, but it seems like good code
hygiene to not call a disconnect function in a different file if no
disconnect happened.

Add new expect_payment_failure_chan_update!() macro in tests

This further DRYs up some functional_test code and increases
coverage.

Merge pull request #976 from TheBlueMatt/2021-06-actionable-errors

Make errors actionable when failing to deserialize a ChannelManager

Merge pull request #954 from TheBlueMatt/2021-06-no-spurious-forward-fails

Consider channels "live" even if they are awaiting a monitor update

Consider channels "live" even if they are awaiting a monitor update

We use `Channel::is_live()` to gate inclusion of a channel in
`ChannelManager::list_usable_channels()` and when sending an
HTLC to select whether a channel is available for
forwarding through/sending to.

In both of these cases, we should consider a channel `is_live()` when
they are pending a monitor update. Some clients may update monitors
asynchronously, thus we may simply be waiting a short duration for a
monitor update to complete, and shouldn't fail all forwarding HTLCs
during that time.

After #851, we always ensure any holding cells are free'd when
sending P2P messages, making this change much more trivially
correct - instead of having to ensure that we always free the holding
cell when a channel becomes live again after adding something to the
holding cell, we can simply rely on the fact that it always happens.

Fixes #661.

Merge pull request #972 from TheBlueMatt/2021-06-skip-notify-chansync

Do not always persist ChannelManager on channel_update messages

Fix unused import in peer_handler introduced in 1f592b045fb6b2788c5

Do not always persist ChannelManager on channel_update messages

If we receive a `channel_update` message for a channel unrelated to
our own, we shouldn't trigger a persistence of our
`ChannelManager`. This avoids significant persistence traffic during
initial node startup.

Correct test log printing due to inverted comparison

We changed the sort order of log levels to be more natural, but this
comparison wasn't updated accordingly. Likely the reason it was
left strange for so long is it also had the comparison argument
ordering flipped.

Make errors actionable when failing to deserialize a ChannelManager

Merge pull request #973 from TheBlueMatt/2021-06-fix-broken-event-ser

Fix bogus `Event::PaymentSent` serialization

Clean up check_spendable_outputs!() test macro somewhat

Merge pull request #965 from TheBlueMatt/2021-06-log-cleanups

Cleanup logging

Add debug log when we stop tracking confirmed on-chain packages

Correct inbound HTLC upgrade logs on revoke_and_ack receipt

Increase the log level of several channelmonitor/onchain logs.

ChannelMonitor and related log entries can generally lean towards
being higher log levels than they necessarily need to be, as they
should be exceedingly rare, if only because they require
confirmation of an on-chain transaction.

Add additional TRACE-level logging during pathfinding in router

Update logging in channel and channelmanager to better levels

This updates a number of log sites in channel and channelmanager to
 * Be a bit more verbose at the TRACE level,
 * Move some error/useful messages to the ERROR/WARN/INFO level,
 * Add new logs to always log once at the DEBUG level when we
   send/receive a commitment_signed (with some extra data),
 * Include the channel id being operated on in more log messages.

Do not log_debug when we receive duplicate gossip messages

We very often receive duplicate gossip messages, which now causes us
to log at the DEBUG level, which is almost certainly not what a
user wants. Instead, we add a new form of ErrorAction which causes
us to only log at the TRACE level.

Allow logging to specify an explicit log level instead of a macro

For log entries which may have a variable level, we can't call an
arbitrary macro and need to be able to pass an explicit level. This
does so without breaking the compile-time disabling of certain log
levels.

Further, we "fix" the comparison order of log levels to make more
significant levels sort "higher", which implicitly makes more sense
than sorting "lower".

Finally, we remove the "Off" log level as no log entry should ever
be logged at the "Off" level - that would be nonsensical.

More consistently log in msg handling, incl full msg logging at trace

This much more consistently logs information about messages
sent/received, including logging the full messages being
sent/received at the TRACE log level. Many other log messages which
are more often of interest were moved to the DEBUG log level.

Unify message sending to use PeerManager::enqueue_message

This makes our logging consistent and somewhat simplifies message
sending code in a few places.

Add error logs when a ChannelManager as inconsistent monitor state

We had a client application which provided inconsistent monitor
state when deserializing a ChannelManager, resulting in opaque and
generic "InvalidData" deserialization failures. Instead, we log
some informative (and appropriately scary) warning messages in
such cases.

Merge pull request #974 from sr-gi/message_signing_borrow

Passes references to the public and secret keys to sign/verify

Merge pull request #966 from TheBlueMatt/2021-06-workaround-broken-lnd

Workaround lnd sending funding_locked before channel_reestablish

Passes references to the public and secret keys to sign/verify

sign/verify should not take ownership of the keys.

Fix bogus `Event::PaymentSent` serialization

`Event::PaymentSent` serialization has a bug where we
double-serialize the payment_preimage field but do not attempt to
read it twice. This results in a failure to read `ChannelManager`s
from disk if we have a pending `Event::PaymentSent` pending
awaiting handling when we serialize.

Instead of attempting to read both versions, we opt to simply fix
the serialization, assuming it is exceedingly rare for such a
scenario to appear (and if it does, we can assist in manual
recovery).

The release notes have been updated to note this inconsistency.

Found by the chanmon_consistency fuzz target.

Workaround lnd sending funding_locked before channel_reestablish

lnd has a long-standing bug where, upon reconnection, if the
channel is not yet confirmed they will not send a
channel_reestablish until the channel locks in. Then, they will
send a funding_locked *before* sending the channel_reestablish
(which is clearly a violation of the BOLT specs). We copy
c-lightning's workaround here and simply store the funding_locked
message until we receive a channel_reestablish.

See-also https://github.com/lightningnetwork/lnd/issues/4006

Fixes #963

Merge pull request #968 from TheBlueMatt/2021-06-no-invoice-dylib

Drop the cdylib export of lightning-invoice

Merge pull request #964 from valentinewallace/2021-06-tlv-ser

Fix TLV serialization to work with large types