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 #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.

Expose the timelock of transaction packages

Simplify tx checks in functional tests to make later commits simpler

This cleans up some of the transaction format verification and docs
to make it easier when we delay CLTV-locked transactions to update
the tests.

Simplify HolderHTLCOutput constructor and track CLTV expiry

This allows us to interrogate a PackageTemplate for the CLTV
timelock of the resulting transaction.

Add assertions to ensure we don't use an invalid package_amount

This somewhat cleans up the public API of PackageSolvingData to
make it harder to get an invalid amount and use it, adding further
debug assertion to check it at test-time.

Merge pull request #928 from TheBlueMatt/2021-05-really-tlv-ser

Migrate some inner structs to TLVs

Update net_graph used for benchmarks to use new ser format.

Migrate packages sub-fields to TLV serialization

Use TLV serialization for Commitment transaction structures

Add TLV suffix to PackageTemplate

Move NetworkGraph inner structs to TLV storage

Move ChannelManager-inner structs to TLV storage

Note that enums are left alone as we can use the type byte already
present for future compatibility.

Add dummy OutPoint constructor to be used when reading it in a TLV

Add a macro which implements Readable/Writeable using TLVs only

This also includes a `VecWriteWrapper` and `VecReadWrapper` which
implements serialization for any `Readable`/`Writeable` type that is
in a Vec. We do this instead of implementing `Readable`/`Writeable`
directly as there isn't always a univerally-defined way to serialize
a Vec and this makes things more explicit.

Finally, this tweaks existing macros (and in the new macros) to
support a trailing `,` after a list, eg
`write_tlv_fields!(stream, {(0, a),}, {});` whereas previously the
trailing `,` after the `(0, a)` would be a compile-error.

Merge pull request #924 from GeneFerneau/alloc

Use alloc for no_std builds

Use alloc for no_std builds

Replace std structs with alloc equivalents to support no_std builds

f use prelude::* credit @devrandom

Fix compile warnings reading type-0 TLVs

Merge pull request #929 from jkczyz/2021-05-json-rpc-error

Parse RPC errors as JSON content

Parse RPC errors as JSON content

Bitcoin Core's JSON RPC server returns errors as HTTP error responses
with JSON content in the body. Parse this content as JSON to give a more
meaningful error. Otherwise, "binary" is given because the content
contains ASCII control characters.

Define an HttpError for returning error contents

Return an HTTP error response as a status code and contents. This allows
clients to interpret the response as desired (e.g., the contents as a
JSON-formatted error).

Merge pull request #642 from ariard/2020-06-anchor-backend-refacto

Anchor-outputs (1/3): Refactoring chain backend to extract PackageTemplate

Add package template unit tests

Move compute_output_value as part of package member functions

Move get_height_timer out of OnchainTxHandler

Move onchain* to chain/

Integrate PackageTemplate

This commit replaces InputMaterial in both ChannelMonitor/
OnchainTxHandler.

This doesn't change behavior.

Duplicate fee computation utilities out of OnchainTxHandler

Duplicated code in onchain.rs is removed in next commits.

Introduce PackageTemplae, a replacement of InputMaterial

PackageTemplate aims to replace InputMaterial, introducing a clean
interface to manipulate a wide range of claim types without
OnchainTxHandler aware of special content of each.

This is used in next commits.

Add package.rs file

Package.rs aims to gather interfaces to communicate between
onchain channel transactions parser (ChannelMonitor) and outputs
claiming logic (OnchainTxHandler). These interfaces are data
structures, generated per-case by ChannelMonitor and consumed
blindly by OnchainTxHandler.

Merge pull request #920 from TheBlueMatt/2021-05-tlv-ser

Rebroadcast channel_announcements when we broadcast a node_announce

Add note in CONTRIBUTING.md that some structs need prefix/suffixes

Rebroadcast channel_announcements when we broadcast a node_announce

Process announcement_signatures messages in Channel and store sigs

Previously we handled most of the logic of announcement_signatures
in ChannelManager, rather than Channel. This is somewhat unique as
far as our message processing goes, but it also avoided having to
pass the node_secret in to the Channel.

Eventually, we'll move the node_secret behind the signer anyway, so
there isn't much reason for this, and storing the
announcement_signatures-provided signatures in the Channel allows
us to recreate the channel_announcement later for rebroadcast,
which may be useful.

Update net graph copy used in tests and bench for new format

Add version and TLV suffix for more user-facing "major" structs

Support serializing TLV fields which may or may not be present

Append backwards-compat TLVs to serialization of larger structs

Currently our serialization is very compact, and contains version
numbers to indicate which versions the code can read a given
serialized struct. However, if you want to add a new field without
needlessly breaking the ability of previous versions of the code to
read the struct, there is not a good way to do so.

This adds dummy, currently empty, TLVs to the major structs we
serialize out for users, providing an easy place to put new
optional fields without breaking previous versions.

Merge pull request #920 from jkczyz/2021-05-event-processing

Background processing of ChannelManager and ChannelMonitor events

Remove event channel from lightning-net-tokio

It is unnecessary since ChannelManager has a notification interface as
of 12c735ab3af8f09dc402f8147594afcc4569be61.

Process ChainMonitor events in the background

Process ChannelManager events in the background

f - Persist when check_free_holding_cells has updates

Guard get_and_clear_pending_msg_events

Remove unnecessary scope from ChannelManager

Refactor EventsProvider to take an EventHandler

Merge pull request #851 from TheBlueMatt/2021-03-holding-cell-clear-msg-get

Clean up and more liberally free holding cell HTLCs (without re-entrancy)

Merge pull request #926 from GeneFerneau/core

Use core replacements for std members

Use core replacements for std members

In preparation for no_std build support, replace std structs and
functions with core equivalents

Add trace to ci-fuzz.sh to make debugging CI issues easier

Log info about HTLC failures when we fail them back

Read monitors from our KeysInterface in chanmon_consistency_fuzz

If the fuzz target is failing due to a channel force-close, the
immediately-visible error is that we're signing a stale state. This
is because the ChannelMonitorUpdateStep::ChannelForceClosed event
results in a signature in the test clone which was deserialized
using a OnlyReadsKeysInterface. Instead, we need to deserialize
using the full KeysInterface instance.

Add a test for HTLC freeing on monitor update restoration

Stop failing back HTLCs on peer disconnection

Previously, if we got disconnected from a peer while there were
HTLCs pending forwarding in the holding cell, we'd clear them and
fail them all backwards. This is largely fine, but since we now
have support for handling such HTLCs on reconnect, we might as
well not, instead relying on our timeout logic to fail them
backwards if it takes too long to forward them.

[fuzz] Handle monitor updates during get_and_clear_pending_msg_events

Because we may now generate a monitor update during
get_and_clear_pending_msg_events calls, we need to ensure we
re-serialize the relevant ChannelManager before attempting to
reload it, if such a monitor update occurred.

Free holding cell on monitor-updating-restored when there's no upd

If there is no pending channel update messages when monitor updating
is restored (though there may be an RAA to send), and we're
connected to our peer and not awaiting a remote RAA, we need to
free anything in our holding cell.

However, we don't want to immediately free the holding cell during
channel_monitor_updated as it presents a somewhat bug-prone case of
reentrancy:
 a) it would re-enter user code around a monitor update while being
    called from user code notifying us of the same monitor being
    updated, making deadlocs very likely (in fact, our fuzzers
    would have a bug here!),
 b) the re-entrancy only occurs in a very rare case, making it
    likely users will not hit it in testing, only deadlocking in
    production.

Thus, we add a holding-cell-free pass over each channel in
get_and_clear_pending_msg_events. This fits up nicely with the
anticipated bug - users almost certainly need to process new
network messages immediately after monitor updating has been
restored to send messages which were not sent originally when the
monitor updating was paused.

Without this, chanmon_fail_consistency was able to find a stuck
condition where we sit on an HTLC failure in our holding cell and
don't ever handle it (at least until we have other actions to take
which empty the holding cell).

DRY ChannelError conversion macros

Both break_chan_entry and try_chan_entry do almost identical work,
only differing on if they `break` or `return` in response to an
error. Because we will now also need an option to do neither, we
break out the common code into a shared `convert_chan_err` macro.

Use new chan_restoration macros in channel_reestablish handling.

This merges the code for restoring channel functionality between
channel monitor updating restored and peer reconnection, reducing
redundant code.

[fuzz] Allow SendAnnouncementSigs events in chanmon_consistency

Because of the merge between peer reconnection and channel monitor
updating channel restoration code, we now sometimes generate
(somewhat spurious) announcement signatures when restoring channel
monitor updating. This should not result in a fuzzing failure.

[fuzz] Be more strict about msg events in chanmon_consistency

This fails chanmon_consistency on IgnoreError error events and on
messages left over to be sent to a just-disconnected peer, which
should have been drained.

These should never appear, so consider them a fuzzer fail case.

Clean up channel updating macro somewhat

This mostly swaps some Vecs that can only ever contain one element
for Options.

Move channel restoration after monitor update to a two-part macro

The channel restoration code in channel monitor updating and peer
reconnection both do incredibly similar things, and there is
little reason to have them be separate. Sadly because they require
holding a lock with a reference to elements in the lock, its not
practical to make them utility functions, so instead we introduce
a two-step macro here which will eventually be used for both.

Because we still support pre-NLL Rust, the macro has to be in two
parts - one which runs with the channel_state lock, and one which
does not.

Drop unused variable and loop in channel_monitor_updated

[fuzz] Print the output of all failed test cases, not one test.

Our fuzz tests previously only printed the log output of the first
fuzz test case to fail. This commit changes that (with lots of
auto-generated updates) to ensure we print all log outputs.

Merge pull request #918 from TheBlueMatt/2021-05-dup-claims

Make payments not duplicatively fail/succeed on reload/reconnect

[fuzz] Make get_secure_random_bytes in chanmon_consistency unique

Test pending payments when resolved duplicatively via reconnect

Test pending payments when duplicatively resolved on chain

Make payments not duplicatively fail/succeed on reload/reconnect

We currently generate duplicative PaymentFailed/PaymentSent events
in two cases:

a) If we receive a update_fulfill_htlc message, followed by a
   disconnect, then a resend of the same update_fulfill_htlc
   message, we will generate a PaymentSent event for each message.

b) When a Channel is closed, any outbound HTLCs which were relayed
   through it are simply dropped when the Channel is. From there,
   the ChannelManager relies on the ChannelMonitor having a copy of
   the relevant fail-/claim-back data and processes the HTLC
   fail/claim when the ChannelMonitor tells it to.

   If, due to an on-chain event, an HTLC is failed/claimed, and
   then we serialize the ChannelManager, but do not re-serialize
   the relevant ChannelMonitor, we may end up getting a duplicative
   event.

In order to provide the expected consistency, we add explicit
tracking of pending outbound payments using their unique
session_priv field which is generated when the payment is sent.
Then, before generating PaymentFailed/PaymentSent events, we check
that the session_priv for the payment is still pending.

Thix fixes #209.

Merge pull request #925 from valentinewallace/ignore-zlib-compressed-msgs

Ignore messages with zlib-compressed fields

Return new DecodeError::UnsupportedCompression

if we receive a message with zlib-compressed values.

Add new DecodeError for messages that include zlib-compressed values

No need to disconnect peers if this error is encountered. It just means
we can't use some of their gossip messages.

Merge pull request #923 from ariard/2021-05-split-sign-justice

Split `sign_justice_transaction` in two halves

keysinterface: replace Result match with map_err

Split `sign_justice_transaction` in two halves

To avoid caller data struct storing HTLC-related information when
a revokeable output is claimed on top of a commitment/second-stage
HTLC transactions, we split `keysinterface::sign_justice_transaction`
in two new halves `keysinterfaces::sign_justice_revoked_output` and
`keysinterfaces::sign_justice_revoked_htlc`.

Further, this split offers more flexibility to signer policy as a
commitment revokeable output might be of a value far more significant
than HTLC ones.

Merge pull request #916 from TheBlueMatt/2021-05-fix-disabled-announcements

Avoid persisting a ChannelManager after each timer tick and send update_channel re-enable messages

Simplify+expand per-channel check in test_announce_disable_channels

Rename Channel::UpdateStatus to be more descriptive and update docs

Do not wait in PersistenceNotifier when the persist flag is set

When we had a event which caused us to set the persist flag in a
PersistenceNotifier in between wait calls, we will still wait,
potentially not persisting a ChannelManager when we should.

Worse, for wait_timeout, this caused us to always wait up to the
timeout, but then always return true that a persistence is needed.

Instead, we simply check the persist flag before waiting, returning
immediately if it is set.

Avoid persisting a ChannelManager update after each timer tick

Currently, when a user calls `ChannelManager::timer_tick_occurred`
we always set the persister's update flag to true. This results in
a ChannelManager persistence after each timer tick, even when
nothing happened.

Instead, we add a new flag to `PersistenceNotifierGuard` to
indicate if we should skip setting the update flag.

Test new channel_update re-enabled announcements

Merge pull request #922 from valentinewallace/update-default-expiry

Correct default invoice expiry

Correct default expiry.

We previously stated in the codebase that the default invoice expiry
stated in the spec is 2 hours. It's actually 1 hour.

Merge pull request #921 from TheBlueMatt/2021-05-no-control-chars

Don't return ASCII control characters in HTTP error messages

Don't return ASCII control characters in HTTP error messages

Send update_channel messages to re-enable a disabled channel

Currently, we only send an update_channel message after
disconnecting a peer and waiting some time. We do not send a
followup when the peer has been reconnected for some time.

This changes that behavior to make the disconnect and reconnect
channel updates symmetric, and also simplifies the state machine
somewhat to make it more clear.

Finally, it serializes the current announcement state so that we
usually know when we need to send a new update_channel.

Merge pull request #919 from valentinewallace/http-error-msgs

Return more error details on http's read_response

Return more error details on http's read_response

Otherwise helpful error information gets swallowed

Merge pull request #915 from TheBlueMatt/2021-05-bump-rpc-timeout

Increase the timeout for RPC responses from Bitcoin Core

Increase the timeout for RPC responses from Bitcoin Core

Early sample testing showed multiple users hitting
EWOULDBLOCK/EAGAIN waiting for an initial response from Bitcoin
Core while it was doing some long operation (eg UTXO cache
flushing). Instead of only waiting 5 seconds for each attempt, we
now wait a full two minutes, but only for the first header
response, not each byte.