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

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

Fix TLV serialization to work with large types.

Previous to this PR, TLV serialization involved iterating from 0 to the highest
given TLV type. This worked until we decided to implement keysend, which has a
TLV type of ~5.48 billion.

So instead, we now specify the type of whatever is being (de)serialized (which
can be an Option, a Vec type, or a non-Option (specified in the serialization macros as "required").

Drop the cdylib export of lightning-invoice

There are ~zero functions in lightning-invoice that are materially
callable from C, so there isn't any reason to tag it as a cdylib
(and make rustc build it as such). Instead, we have C bindings now.

Merge pull request #950 from TheBlueMatt/2021-06-changelog

Add a dummy first CHANGELOG entry for future tracking

Add a dummy first CHANGELOG entry for future tracking

Do not generate error messages when we receive our own gossip

When a peer sends us the routing graph, it may include gossip
messages for our channels, despite it not being a party to them.
This is completely fine, but we currently print a somewhat-scary
looking log messages in these cases, eg:

```
ERROR [lightning::ln::channelmanager:4104] Got a message for a channel from the wrong node!
TRACE [lightning::ln::peer_handler:1267] Handling SendErrorMessage HandleError event in peer_handler for node ... with message Got a message for a channel from the wrong node!
```

Instead, we should simply not consider this an "error" condition
and stay silent.

Drop rust-bitcoin crate patches in fuzz now that they're merged

These patches have been merged upstream and are in releases now so
we don't need to patch them locally.

log_debug information about network graph updates from payments

Don't print file paths in fuzz logger as they can be very long

Merge pull request #957 from TheBlueMatt/2021-06-p2p-no-deadlock

Fix P2P Deadlocks

Clean up docs on peer_handler significantly.

There are various typo and grammatical fixes here, as well as
concrete updates to correctness.

No longer block disconnect_socket calls in lightning-net-tokio

See the previous commit for more information.

Do not require that no calls are made post-disconnect_socket

The only practical way to meet this requirement is to block
disconnect_socket until any pending events are fully processed,
leading to this trivial deadlock:

 * Thread 1: select() woken up due to a read event
 * Thread 2: Event processing causes a disconnect_socket call to
             fire while the PeerManager lock is held.
 * Thread 2: disconnect_socket blocks until the read event in
             thread 1 completes.
 * Thread 1: bytes are read from the socket and
             PeerManager::read_event is called, waiting on the lock
             still held by thread 2.

There isn't a trivial way to address this deadlock without simply
making the final read_event call return immediately, which we do
here. This also implies that users can freely call event methods
after disconnect_socket, but only so far as the socket descriptor
is different from any later socket descriptor (ie until the file
descriptor is re-used).

Merge pull request #948 from TheBlueMatt/2021-06-p2p-fixes

Clean up message forwarding and relay gossip messages

[peer_handler] Drop unused return from get_peer_for_forwarding!()

This avoids a now-unnecessary SocketDescriptor clone() call in
addition to cleaning up the callsite code somewhat.

Somewhat simplify message handling error mapping in peer_handler

Drop peers_needing_send tracking and try to write for each peer

We do a lot of work to track which peers have buffers which need
to be flushed, when we could instead just try to flush ever peer's
buffer.

Skip forwarding gossip messages to peers if their buffer is over-full

Forward gossip msgs

Refactor message broadcasting out into a utility method

This will allow us to broadcast messages received in the next
commit.

Fix bogus reentrancy from read_event -> do_attempt_write_data

`Julian Knutsen <julianknutsen@users.noreply.github.com>` pointed
out in a previous discussion that `read_event` can reenter user
code despite the documentation stating explicitly that it will not.

This was addressed in #456 by simply codifying the reentrancy, but
its somewhat simpler to just drop the `do_attempt_write_data` call.

Ideally we could land most of Julian's work, but its still in need
of substantial git history cleanup to get it in a reviewable state
and this solves the immediate issue.