[bindings] Use resolved, not local ident in generic mangling

In traits with associated types which are returned in generics (ie
`trait T { type A: B; fn c() -> Result<Self::A, ()> {} }`), we
created a new generic mapping with the local type name (in this
case A) instead of using the real type (in this case B). This is
confusing as it results in generic manglings that don't reference
the real type (eg `LDKCResult_ChanKeySignerDecodeErrorZ`) and
may have multiple generic definitions that are identical.

Instead, we now use the final ident in the resolved mapping. The
biggest win is `LDKCResult_ChanKeySignerDecodeErrorZ` changing to
`CResult_ChannelKeysDecodeErrorZ`. However, there are several types
where `secp256k1::Error` was imported as `SecpError` and types like
`LDKCResult_SecretKeySecpErrorZ` are now
`LDKCResult_SecretKeyErrorZ` instead. Still, the type of the error
field remains `LDKSecp256k1Error`, which should avoid any confusion.

[bindings] Drop some significantly-overly-verbose logging in gen

Merge pull request #788 from TheBlueMatt/2020-02-concrete-bindings

Concretize bindings templates

Update auto-generated bindings

Add additional Clone derives

The only API change outside of additional derives is to change
the inner field in `DecodeError::Io()` to an `std::io::ErrorKind`
instead of an `std::io::Error`. While `std::io::Error` obviously
makes more sense in context, it doesn't support Clone, and the
inner error largely doesn't have a lot of value on its own.

[bindings] Allow cloning opaque types when inner is NULL

Previously we'd segfault trying to deref the NULL page, but there
is no reason to not simply clone by creating another opaque instance
with a null inner. This comes up specifically when cloning
ChannelSigners as the pubkeys instance is NULL on construction
before get_pubkeys is called.

[C++ bindings] Update demo app due to removed TupleTempl generics

[bindings] Drop some stale code from bindings generic generation

[bindings] Move to manual write-out for Tuples, too

[bindings] Move to manual write-out for Vec, too

[bindings] Concretize Result types without type aliasing

While the type aliasing trick works great for cbindgen,
wasm_bindgen doesn't support it and requires fully-concrete types.
In order to better support wasm_bindgen in the future, we do so
here, adding a function which manually writes out almost the exact
thing which was templated previously in concrete form.

As a nice side-effect, we no longer have to allocate and free a u8
for generic parameters which were `()` (though we still do in some
conversion functions, which we can get rid of when we similarly
concretize all generics fully).

[bindings] Keep track of all types which derive[Clone]

[bindings] Add additional clone methods on manually-defined types

Merge pull request #787 from TheBlueMatt/2021-02-check-close-source

Fix documentation on PeerHandleError

Add test for error message hangline resulting in force-close

Check the PK of the source of an error before closing chans from it

When we receive an error message from a peer, it can indicate a
channel which we should close. However, we previously did not
check that the counterparty who sends us such a message is the
counterparty with whom we have the channel, allowing any
connected peer to make us force-close any channel we have as long
as they know the channel id.

This commit simply changes the force-close logic to check that the
sender matches the channel's counterparty node_id, though as noted
in #105, we eventually need to change the indexing anyway to allow
absurdly terrible peers to open channels with us.

Found during review of #777.

Merge pull request #793 from galderz/t_double_validation_792

Unknown bits feature only needs to be validated once #792

Merge pull request #790 from bmancini55/sync_complete

Interpret sync_complete in reply_channel_range

Merge pull request #774 from jkczyz/2021-01-http-client

HTTP-based block source clients

Implement BlockSource for REST and RPC clients

Interprets HTTP responses as either binary or JSON format, which are
then converted to the appropriate data types.

Add REST and RPC clients to lightning-block-sync

Implements a simple HTTP client that can issue GET and POST requests.
Used to implement REST and RPC clients, respectively. Both clients
support either blocking or non-blocking I/O.

Interpret sync_complete in reply_channel_range

LN Spec PR #826 changes full_information to indicate completion of a
sequence of reply_channel_range messages.

Add lightning-block-sync package and library

Defines an interface and related types for fetching block headers and
data from a block source (e.g., Bitcoin Core). Used to keep lightning in
sync with chain activity.

Merge pull request #768 from TheBlueMatt/2020-12-chanman-bindings-deser

Expose ChannelManager/Monitor read methods in bindings

[bindings] Fix genbindings.sh compile issues on OSX

There were two issues on OSX - we need to give gcc the clang
warnings flags because `gcc` *is* clang on OSX and we missed an
`-std=c++11` on one of the clang++ calls, causing compile failures.

Update C++ bindings demo to use `ChannelManager` de/serialization

This demonstrates (and tests) the newly-exposed `ChannelManager`
de/serialization functions. Best revewied with -b --color-moved.

[C++ bindings demo] Add now-missing std::moves

Auto-generated bindings updates

[C++ bindings] Add move-assign operator, require rvalue for move

This adds a move-assignment operator (`A& operator=(A&& o)`) to our
C++ wrapper classes as well as requiring an rvalue for the move
auto-convert operator (`operator CStruct()() &&`).

The second makes the C++ wrapper classes much easier to work with
by requiring an explicit `std::move` when the bindings will
automatically move a C++-wrapper object into a C object.

[bindings] Use references in a few places instead of pointers

Previously, references and pointers ended up identical in C, so
there was little reason to differentiate. With the addition of
nullability annotations, there is a (very slight) reason to prefer
references, so use them in a few places where its a trivial change.

[bindings] Use new non-null annotation feature in cbindgen

This adds a new annotation for objects we take by reference in the
C header indicating the pointers must not be null. We have to
disable some warning clang now dumps that we haven't annotated all
pointers, as cbindgen is not yet able to add a nullable annotation.

[bindings] Don't require trait impl for-structs to have no generics

This (finally) exposes `ChannelManager`/`ChannelMonitor` _write
methods, which were (needlessly) excluded as the structs themselves
have generic parameters. Sadly, we also now need to parse
`(C-not exported)` doc comments on impl blocks as we otherwise try
to expose _write methods for `&Vec<RouteHop>`, which doesn't work
(and isn't particularly interesting for users anyway). We add such
doc comments there.

[bindings] Implement ReadableArgs mapping, try impl mapping for ()s

This is most of the code to expose `ChannelManager`/`ChannelMonitor`
deserialization in our C bindings, using the new infrastructure to
map types in `maybe_convert_trait_impl` and passing generics in
from the callsites.

We also call `maybe_convert_trait_impl` for tuple types, as the
`ChannelManager`/`ChannelMonitor` deserialization returns a
`(BlockHash, T)` to indicate the block hash at which users need to
start resyncing the chain.

The final step to expose them is in the next commit.

[bindings] Allow `write_rust_type` to handle leading-colon paths

It just stubs out to `write_rust_path` in this case anyway, which
handles leading-colons just fine, so no need to panic on them.

[bindings] Use common conv in `_write` impls, drop type restrictions

This expands the manual implementation logic for `*_write` and
`*_read` methods to most types, converting the `*_write` path to
the common type-conversion logic to ensure it works.

Note that `*_write_void` is still only implemented for has-inner
types, as its unclear what the `void*` would point to for others.

[bindings] Convert manual `_read` implementations to return Results

Previously, manual `*_read` implementations were only defined for
types with inner fields, which were set to NULL to indicate read
errors. This prevents exposing `*_read` for several other types,
including tuples (which are needed for `ChannelManager`/
`ChannelMonitors`) and enums (which includes `Event`s, though users
likely never need to call that directly). Further, this means we
don't expose the actual error enum (which is likely no big deal,
but is still nice).

Here, we instead create the `Result<Object, DecodeError>` type and
then pass it through the normal type conversion functions, giving
us access to any types which we can convert normally.

[bindings] Pipe errors back from write_template_constructor

We can fail to resolve a part of a tuple, resulting in a panic in
write_template_constructor even if we're calling
`understood_c_type` with the intent of figuring out whether we can
print a type at all. Instead, we should pipe errors back and let
`understood_c_type` return false as a result.

Merge pull request #767 from TheBlueMatt/2020-12-chansigner-read-bindings

Handle `read_chan_signer` in bindings (761 bindings updates)

Merge pull request #781 from TheBlueMatt/2021-01-tokio-1

Update tokio to 1.0

[bindings] Update C++ demo for new NetGraphMsgHandler::new() params

Update auto-generated bindings, including bumping cbindgen version

[bindings] Allow unused fns that the bindings can call but don't

We no longer have any public `Option<Signatures>` in our code, and
thus get warnings that the two functions which support it are
unused. Instead of removing support for them (which we may need in
the future), we add `#[allow(unused)]`.

[bindings] Drop useless `#[no_mangle]` from `pub type` definitions

Newer rustc complains that "attribute should be applied to a function or
static"

[bindings] Be explicit with take_ptr calls

If you try to call take_ptr on a pointer to an object which
implements Deref, rustc hits the deref recursion limit.

To avoid this, we can explicitly tell rustc that we want to treat
the pointer as a pointer and call take_ptr on it directly.

[bindings] Separate take_ptr and take_inner

It is confusing to have two utility methods on different classes
of types which do two different, but related, things with the same
name.

[bindings] Support exposing `bitcoin::OutPoint`s as our common type

[bindings] Figure out in-file structs and enums before processing

Previously, types which were declared and used in the same file
would fail if the use was before the declaration. This makes sense
in a few cases where a "parent" class returns a reference to a
"child" class and there's no reason we shouldn't support it.

This change adds a second pass to our file processing which gathers
the structs and enums whicha re declared in the file and adds them
to the type resolver first, before doing the real conversion.

[bindings] Don't export new functions with unexportable types

`CommitmentTransaction::new_with_auxiliary_htlc_data()` includes a
unbounded generic parameter which we can't concretize and it's of
limited immediate use for users in any case. We should eventually
add a non-generic version which uses `()` for the generic but that
can come later.

`CommitmentTransaction::htlcs()` returns a reference to a Vec,
which we cannot currently map. It should, however, be exposed to
users, so in the future we'll need to have a duplication function
which returns Vec of references or a cloned Vec.

[bindings] Expose secp256k1::Message as ThirtyTwoBytes

[bindings] Add support for mapping Write as a supertrait

[bindings] Handle MessageSendEventsProvider impl blocks in a util fn

Instead of having manually-written lightning-specific code in a
supertrait walk in the middle of a large function, move it to a
utility function up next to the other manually-written-impl-block
functions.

[bindings] Always resolve supertrait types during supertrait walks

This is a rather trivial cleanup to ensure we always have the full
path when we walk supertraits even if the supertrait is specified
with only a single ident.

[bindings] Pass GenericTypes through to write_template_generic

With this we support types like `Result<Self::AssociatedType, ()>`.

[bindings] Un-special-case returning an associated type

In the case that we return an associated type to C (ie when
implementing a trait which returns an associated type, we had to
convert the Rust-returned concrete Rust type to the C trait struct),
we had code to manually create the neccessary trait struct at the
return site.

This was special-cased in the method-body-writing function instead
of letting the type conversion logic handle it. As a result, we are
unable to do the same conversion when it appears in a different
context, for example inside of a generic like
`Result<Self::AssocType, ErrorType>`.

To solve this, we do the actual work in a
`impl From<nativeType> for CTraitStruct` implementation and then
call `into()` from within the type conversion logic.

[bindings] Replace associated_types HashMaps with common Generics

Instead of handling associated types separately, we can just shove
them into the same generics resolution logic we use for template
types. While we should probably have some precedence logic,
aliasing type names seems like a bad idea anyway so no effort is
made to handle it.

This removes a good chunk of code and, more importantly, tees us up
for supporting `Type<Self::AssociatedType>`-style generics.

Drop spurious semicolon that new rustc complains about

[bindings] Use consistent imports for MessageSendEvents traits

Our bindings generator is braindead with respect to the idents
used in a trait definition - it treats them as if they were used
where the trait is being used, instead of where the trait is
defined. Thus, if the idents used in a trait definition are not
also imported the same in the files where the traits are used, we
will claim the idents are bogus.

I spent some time trying to track the TypeResolvers globally
through the entire conversion run so that we could use the original
file's TypeResolver later when using the trait, but it is somewhat
of a lifetime mess. While likely possible, import consistency is
generally the case anyway, so unless it becomes more of an issue in
the future, it likely makes the most sense to just keep imports
consistent.

This commit keeps imports consistent across trait definition files
around `MessageSendEvent` and `MessageSendEventsProvider`.

strip binaries in genbindings.sh for better size comparison

Merge pull request #783 from ariard/2021-01-disconnect-node-id

Add PeerManager::disconnect_node_id()

Add PeerManager::disconnect_by_node_id()

This public method allows a client to easily disconnect peers while only
owning its node id. It will clean up peer state and disconnect properly
its descriptor.

Fix codecov by calling the new binary paths from rust 1.45

Rustc 1.45 moved the paths to test binaries, so we need to update
our CI scripts to run the correct ones under kcov.

The solution to this was pointed out by Val at
https://github.com/rust-bitcoin/rust-lightning/pull/774#issuecomment-763250623

Bump MSRV for net-tokio to 1.45 as tokio 1.0 req very recent rustc

Update tokio to 1.0

This requires ensuring TcpStreams are set in nonblocking mode as
tokio doesn't handle this for us anymore, so we adapt the public
API to just accept std TcpStreams instead of an extra conversion
hop. Luckily converting them is cheap.

Merge pull request #764 from lightning-signer/revoke-enforcement

Revocation enforcement

Merge pull request #777 from sr-gi/cm-force-close-checks

Makes ChannelManager::force_close_channel fail for unknown chan_ids

Let some tests disable revocation policy check

When simulating a bad actor that broadcasts a revoked tx, the policy check would otherwise panic.

Makes ChannelManager::force_close_channel fail for unknown chan_ids

ChannelManager::force_close_channel does not fail if a non-existing channel id is being passed, making it hard to catch from an API point of view.

Makes force_close_channel return in the same way close_channel does so the user calling the method with an unknown id can be warned.

Fix fuzzing issue with revocation

Revocation enforcement in signer

We want to make sure that we don't sign revoked transactions.

Given that ChannelKeys are not singletons and revocation enforcement is stateful,
we need to store the revocation state in KeysInterface.

Use TestKeysInterface in functional tests

This allows stateful validation in EnforcingChannelKeys

Merge pull request #770 from lightning-signer/holder-htlc-sigs

Fold sign_holder_commitment_htlc_transactions into sign_holder_commitment

Simplify handling of OnChainTx.holder_commitment

It is no longer optional since it is available at construction time.

Panic if signing fails in OnChainTx

Signatures in OnChainTx must not fail, or we stand to lose funds

Fold sign_holder_commitment_htlc_transactions into sign_holder_commitment

Signing the commitment transaction is almost always followed by signing the attached HTLC transactions, so fold the signing operations into a single method.

Merge pull request #776 from valentinewallace/update-readme

Update readme

Merge pull request #772 from ariard/2021-01-getting-project-context

Add GLOSSARY.md and more

Extend Getting Started with GLOSSARY/meeting minutes  in CONTRIBUTING.md

Add a GLOSSARY.md

Closes #766

Contributions by Devrandom <c1.devrandom@niftybox.net>

Update README with RL customization details

Merge pull request #771 from jkczyz/2021-01-bolt3-test-vectors

Add BOLT 3 test vector for CLTV tiebreaker

Add BOLT 3 test vector for CLTV tiebreaker

The test vector was added in https://github.com/lightningnetwork/lightning-rfc/pull/539.

Merge pull request #761 from TheBlueMatt/2020-10-chansigner-no-ser

Add a new method `read_chan_signer` to `KeysInterface`

Merge pull request #769 from sr-gi/copy-trait-config

Adds Copy to ChannelHandshakeConfig and UserConfig

Adds Copy to ChannelHandshakeConfig and UserConfig

This commits adds Copy to ChannelHandshakeConfig and UserConfig for consistency with the rest of config structs.

Use `KeysInterface::read_chan_signer` for all channel keys deser

This drops any direct calls to a generic `ChannelKeys::read()` and
replaces it with the new `KeysInterface::read_chan_signer()`. Still,
under the hood all of our own `KeysInterface::read_chan_signer()`
implementations simply call out to a `Readable::read()` implemention.

Expose test_utils to fuzztarget (in addition to _test_utils feature)

Add a new method `read_chan_signer` to `KeysInterface`

This adds a new method to the general cross-channel `KeysInterface`
which requires it to handle the deserialization of per-channel
signer objects. This allows the deserialization of per-channel
signers to have more context available, which, in the case of the
C bindings, includes the actual KeysInterface information itself.

Use Writeable for ChannelMonitor instead of a specific function.

There's no reason to have ChannelMonitor::write_for_disk instead of
just using the Writeable trait anymore. Previously, it was used to
differentiate with `write_for_watchtower`, but support for
watchtower-mode ChannelMonitors was never completed and the partial
bits were removed long ago.

This has the nice benefit of hitting the custom Writeable codepaths
in C bindings instead of trying to hit trait-generics paths.

Universally Require Writeable for ChannelKeys

It doesn't make sense to ever build a lightning node which doesn't
ever write ChannelMonitors to disk, so having a ChannelKeys object
which doesn't implement Writeable is nonsense.

Here we require Writeable for all ChannelKeys objects, simplifying
code generation for C bindings somewhat.

Cache fields instead of storing a ChannelKeys in ChannelMonitor

We only actually use two of the fields in ChannelKeys inside a
ChannelMonitor - the holder revocation_basepoint and the
derivation parameters. Both are relatively small, so there isn't
a lot of reason to hold a full copy of the ChannelKeys (with most
of the interaction with it being inside the OnchainTxHandler).

Further, this will avoid calling read on a `ChannelKeys` twice,
which is a somewhat strange API quirk.

Merge pull request #742 from lightning-signer/tx-phase2

Introduce CommitmentTransactionInfo

Use new get_commitment_transaction_number_obscure_factor utility function

Introduce CommitmentTransaction, ChannelTransactionParameters

CommitmentTransaction maintains the per-commitment transaction fields needed to construct the associated bitcoin transactions (commitment, HTLC).  It replaces passing around of Bitcoin transactions.  The ChannelKeys API is modified accordingly.

By regenerating the transaction when implementing a validating external signer, this allows a higher level of assurance that all relevant aspects of the transactions were checked for policy violations.

ChannelTransactionParameters replaces passing around of individual per-channel fields that are needed to construct Bitcoin transactions.

Eliminate ChannelStaticData in favor of ChannelTransactionParameters.

Use counterparty txid instead of tx in channelmonitor update.

Unwrap unneeded macros

Merge pull request #736 from bmancini55/gossip_queries

Initiate gossip_queries

Fix comment for sync_routing_table

Corrects the comment for sync_routing_table in RoutingMessageHandler to
be less prescriptive about the implementor's actions.

Remove should_request_full_sync from RoutingMessageHandler

This method was used to set the initial_routing_sync flag when sending
an outbound Init message to a peer. Since we are now relying on
gossip_queries instead of initial_routing_sync, synchronization can be
fully encapsulate into RoutingMessageHandler via sync_routing_table.

This commit removes should_request_full_sync from the trait
RoutingMessageHandler. The implementation is still used in
NetGraphMsgHandler and has been converted into a private method instead
of a trait function.

Change routing table sync to use gossip_queries

This commit changes outbound routing table sync to use gossip_queries
instead of the effectively deprecated initial_routing_sync feature.

This change removes setting of initial_routing_sync in our outbound Init
message. Instead we now call sync_routing_table after receiving an Init
message from a peer. If the peer supports gossip_queries and
should_request_full_sync returns true, we initiate a full gossip_queries
sync.