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

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

Cache socket address in HttpClient for reconnect

If the HttpClient attempts to reconnect to bitcoind that is no longer
running, the client fails to get the address from the stream. Cache the
address when connecting to prevent this.

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.