Make errors actionable when failing to deserialize a ChannelManager

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.

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.

Drop unused "peer gone" handling in get_peer_for_forwarding!()

We can never assume that messages were reliably delivered whether
we placed them in the socket or not, so there isn't a lot of use in
explicitly handling the case that a peer was not connected when we
went to send it a message.

Two TODOs are left for the generation of a `FundingAbandoned` (or
similar) event, though it ultimately belongs in `ChannelManager`.

Merge pull request #947 from GeneFerneau/hash

Use hashbrown replacements for std equivalents

Use hashbrown replacements for std equivalents

Merge pull request #956 from jkczyz/2021-06-validate-pub

Increase poll::Validate visibility to pub

Merge pull request #955 from TheBlueMatt/2021-06-rustc-bugz

Fix trivial doc warnings and make CI use old rustc

Remove unnecessary spaces

Increase poll::Validate visibility to pub

Previously, poll::Validate was pub(crate) to force external implementors
of Poll to define their implementation in terms of ChainPoller. This was
because ChainPoller::look_up_previous_header checks for consistency
between headers and any errors would be checked at that level rather
than by the caller. Otherwise, if performed by the caller, a Poll
implementation would not be aware if the underlying BlockSource was
providing bad data and therefore couldn't react accordingly.

Widening the visibility to pub relaxes this requirement, although it's
still encourage to use ChainPoller to implement Poll. This permits
either copying or moving lightning-block-sync's test utilities to a
separate crate since they use poll::Validate.

Clarify invoice comment noting the relevant final-cltv-expiry vals

Make links in message signing docs rustdoc links

Latest rustc warns that "this URL is not a hyperlink" and notes that
"bare URLs are not automatically turned into clickable links". This
resolves those warnings.

Thanks to Joshua Nelson for pointing out the correct syntax for
this.

Expose doc-linked constants in lightning-invoice

These constants are generally useful, and are linked from
documentation, so should be exposed in any case.

Only check docs on rustc 1.52 as rustc stable now crashes

Merge pull request #944 from TheBlueMatt/2021-06-0.0.99

0.0.98

Merge pull request #946 from jkczyz/2021-06-get-route-interface

Align get_route's interface with ChannelManager and Invoice

Fix type name in docs

Accept multi-hop route hints in get_route

Lightning invoices allow for zero or more multi-hop route hints. Update
get_route's interface to accept such hints, although only the last hop
from each is used for the time being.

Moves RouteHint from lightning-invoice crate to lightning crate. Adds a
PrivateRoute wrapper around RouteHint for use in lightning-invoice.

Add find_all_extract macro to lightning-invoice

Used for extracting more than one field of the same type.

Bump versions to 0.0.98, lightning-invoice to 0.6.0

Merge pull request #940 from TheBlueMatt/2021-06-fix-docs

Clean up docs on public chan_utils methods to be more useful

Merge pull request #936 from TheBlueMatt/2021-05-spendable-event-locktime-delay

Delay DelayedPaymentOutput spendable events until the CSV delay

Merge pull request #943 from lightning-signer/2021-06-signet

Add proper signet support for invoices

Clean up docs on public chan_utils methods to be more useful

Merge pull request #939 from TheBlueMatt/2021-05-derives

Add additional derives for a few structs

Merge pull request #942 from lightning-signer/2021-06-accept-channel-reserve-dust

Remove unwanted check in accept_channel

Add proper signet support for invoices

Remove unwanted check in accept_channel

This caused an interoperability issue with lnd, because they can propose a reserve lower than their dust limit (but not lower than ours).

Add additional derives for a few structs

Delay DelayedPaymentOutput spendable events until the CSV delay

Merge pull request #935 from TheBlueMatt/2021-05-enum-tlvs

TLV-ize enum serialization and a few additional structs

Update network graph sample used in benchmarks

Convert SpendableOutputDescriptor to new TLV-based serialization

Clean up ChannelMonitor object serialization to use TLVs/versions

Use TLVs inside of serialization of Event variants

Convert remaining channel inner structs and enums to TLV-based ser

Convert most chain::* inner structs and enums to TLV-based ser macros

Add generic serialization implementations for Boxs and 3-tuples

These are used in the next commit(s).

Use TLV instead of explicit length for VecReadWrapper termination

VecReadWrapper is only used in TLVs so there is no need to prepend
a length before writing/reading the objects - we can instead simply
read until we reach the end of the TLV stream.

Add a macro to implement serialization of enums using TLVs

Merge pull request #938 from lightning-signer/2020-06-test-background

Expose test_process_background_events

Expose test_process_background_events

Give OnchainEvent::HTLCUpdate individual fields instead of a pair

Merge pull request #933 from TheBlueMatt/2021-05-ser-fast

Speed up deserialization of secp256k1 objects significantly

Add additional inline hints in serialization methods

This substantially improves deserialization performance when LLVM
decides not to inline many short methods, eg when not building
with LTO/codegen-units=1.

Even with the default bench params of LTO/codegen-units=1, the
serialization benchmarks on an Intel 2687W v3 take:

test routing::network_graph::benches::read_network_graph  ... bench: 1,955,616,225 ns/iter (+/- 4,135,777)
test routing::network_graph::benches::write_network_graph ... bench: 165,905,275 ns/iter (+/- 118,798)

Impl `serialized_length()` without `LengthCalculatingWriter`

With the new `serialized_length()` method potentially being
significantly more efficient than `LengthCalculatingWriter`, this
commit ensures we call `serialized_length()` when calculating
length of a larger struct.

Specifically, prior to this commit a call to
`serialized_length()` on a large object serialized with
`impl_writeable`, `impl_writeable_len_match`, or
`encode_varint_length_prefixed_tlv` (and
`impl_writeable_tlv_based`) would always serialize all inner fields
of that object using `LengthCalculatingWriter`. This would ignore
any `serialized_length()` overrides by inner fields. Instead, we
override `serialized_length()` on all of the above by calculating
the serialized size using calls to `serialized_length()` on inner
fields.

Further, writes to `LengthCalculatingWriter` should never fail as
its `write` method never returns an error. Thus, any write failures
indicate a bug in an object's write method or in our
object-creation sanity checking. We `.expect()` such write calls
here.

As of this commit, on an Intel 2687W v3, the serialization
benchmarks take:

test routing::network_graph::benches::read_network_graph  ... bench: 2,039,451,296 ns/iter (+/- 4,329,821)
test routing::network_graph::benches::write_network_graph ... bench: 166,685,412 ns/iter (+/- 352,537)

Avoid calling libsecp serialization fns when calculating length

When writing out libsecp256k1 objects during serialization in a
TLV, we potentially calculate the TLV length twice before
performing the actual serialization (once when calculating the
total TLV-stream length and once when calculating the length of the
secp256k1-object-containing TLV). Because the lengths of secp256k1
objects is a constant, we'd ideally like LLVM to entirely optimize
out those calls and simply know the expected length. However,
without cross-language LTO, there is no way for LLVM to verify that
there are no side-effects of the calls to libsecp256k1, leaving
LLVM with no way to optimize them out.

This commit adds a new method to `Writeable` which returns the
length of an object once serialized. It is implemented by default
using `LengthCalculatingWriter` (which LLVM generally optimizes out
for Rust objects) and overrides it for libsecp256k1 objects.

As of this commit, on an Intel 2687W v3, the serialization
benchmarks take:

test routing::network_graph::benches::read_network_graph  ... bench: 2,035,402,164 ns/iter (+/- 1,855,357)
test routing::network_graph::benches::write_network_graph ... bench: 308,235,267 ns/iter (+/- 140,202)

Drop byte_utils in favor of native `to/from_be_bytes` methods

Now that our MSRV supports the native methods, we have no need
for the helpers anymore. Because LLVM was already matching our
byte_utils methods as byteswap functions, this should have no
impact on generated (optimzied) code.

This removes most of the byte_utils usage, though some remains to
keep the patch size reasonable.

Add bench profiles to Cargo.toml to force codegen-units=1

This makes a small difference for NetworkGraph deserialization
as it enables more inlining across different files, hopefully
better matching user performance as well.

As of this commit, on an Intel 2687W v3, the serialization
benchmarks take:

test routing::network_graph::benches::read_network_graph  ... bench: 2,037,875,071 ns/iter (+/- 760,370)
test routing::network_graph::benches::write_network_graph ... bench: 320,561,557 ns/iter (+/- 176,343)

Add benchmark of deserializing a NetworkGraph.

NetworkGraph is one of the largest structures we generally
deserialize, so it makes for a good benchmark, even if it isn't the
most complicated one.

As of this commit, on an Intel 2687W v3, these benchmarks take:

test routing::network_graph::benches::read_network_graph  ... bench: 2,101,420,078 ns/iter (+/- 6,649,020)
test routing::network_graph::benches::write_network_graph ... bench: 344,696,835 ns/iter (+/- 229,061)

Merge pull request #892 from TheBlueMatt/2021-04-fix-htlc-ser

Correct Channel outbound HTLC serialization and expand fuzzing coverage

Merge pull request #934 from TheBlueMatt/2021-05-new-tag

Add new `(C-not implementable)` tag on `EventsProvider`

Correct Channel outbound HTLC serialization

Channel serialization should happen "as if
remove_uncommitted_htlcs_and_mark_paused had just been called".

This is true for the most part, but outbound RemoteRemoved HTLCs
were being serialized as normal, even though
`remote_uncommitted_htlcs_and_mark_paused` resets them to
`Committed`.

This led to a bug identified by the `chanmon_consistency_target`
fuzzer wherein, if we receive a update_*_htlc message bug not the
corresponding commitment_signed prior to a serialization roundtrip,
we'd force-close the channel due to the peer "attempting to
fail/claim an HTLC which was already failed/claimed".

[fuzz] Expand chanmon_consistency to do single message delivery

While trying to debug the issue ultimately tracked down to a
`PeerHandler` locking bug in #891, the ability to deliver only
individual messages at a time in chanmon_consistency looked
important. Specifically, it initially appeared there may be a race
when an update_add_htlc was delivered, then a node sent a payment,
and only after that, the corresponding commitment-signed was
delivered.

This commit adds such an ability, greatly expanding the potential
for chanmon_consistency to identify channel state machine bugs.

[fuzz] Fix hang due to double-lock in full_stack_target

[fuzz] Do not fail in FST if a channel is closed before we fund it

Merge pull request #931 from jkczyz/2021-05-http-client-reconnect

Cache socket address in HttpClient for reconnect

Add new `(C-not implementable)` tag on `EventsProvider`

This makes it so that users cannot usefully implement their own
`EventsProvider`, which would require substantial new logic in the
bindings generator (for generic methods). In the case of
`EventsProvider`, because there are no Rust methods which accept an
`EventsProvider` as an argument, this is perfectly OK as the
generated code would be entirely unused anyway.

Merge pull request #932 from TheBlueMatt/2021-05-broadcast-locktime-delay

Broadcast transactions only after their timelock is up

panic if locktime is violated when broadcasting in tests

Dont broadcast HTLC-Timeouts when closing a channel until locktime

Skip transactions which are locktime'd when broadcasting in test

Track the blocks a node has connected in the TestBroadcaster

Delay broadcast of PackageTemplate packages until their locktime

This stores transaction templates temporarily until their locktime
is reached, avoiding broadcasting (or RBF bumping) transactions
prior to their locktime. For those broadcasting transactions
(potentially indirectly) via Bitcoin Core RPC, this ensures no
automated rebroadcast of transactions on the client side is
required to get transactions confirmed.

Always pass height to OnchainTxHandler::update_claims_view

This simplifies logic somewhat and avoids duplicating the storage
of the current height in OnchainTxHandler.