Merge pull request #795 from TheBlueMatt/2021-02-features-bindings

Map Features objects in bindings

Merge pull request #789 from TheBlueMatt/2021-02-chansigner-util-fns

Add util fn for creating a Transaction from spendable outputs

Update auto-generated bindings

[bindings] Silence c-bindings-gen compile warnings

[bindings] Handle `impl Clone` like `impl ::core::clone::Clone`

[bindings] Drop manual implementations of Features conversion

We now handle features properly in our own resolution, and these
appear to be self-inconsistent in some cases.

[bindings] Handle generic-ized impl blocks by concretizing them

This handles, for example, the `impl<X: Y> for Features<X>` blocks
which are generic across a number of different contexts. We do so
by walking the set of structs which alias Features and then walking
their generic arguments to check that they meet the bounds
specified in the impl block. For each alias which does, we create
a dummy, explicit, `impl XFeatures` block with the same content as
the original and recurse.

[bindings] Resolve type aliases mapped as opaque types

We already map type aliases which alias private types as opaque,
but we don't resolve them like we would any other opaque type,
preventing conversion printing or type use.

[bindings] Track structs impling traits, incl priv traits

[bindings] Allow resolution of private types in some cases

We need this specifically for resolving the
features::sealed::Context trait which is inside the non-pub
`sealed` module.

Drop a useless import and use `Self` in return values in Features

`Result` is in the standard prelude, so no need to ever use it.

Sadly, returning a Features<T> in the `impl Futures {}` block
will confuse our new alias-impl-printing logic, as we end up
running through the normal impl-block-printing logic as if we had
an explicit `impl ConcreteFeatures` block.

[bindings] Use new ImportResolver during first AST pass

This removes some redundant logic and ensures we handle more
import-resolution cases in both contexts.

[bindings] Track all declared types in ImportResolver construction

This allows an ImportResolver to handle more than imports, allowing
ident resolution of objects constructed in the same module.

[bindings] Extract import resolution logic into a separate struct

This will allow us to reuse the same ident-resolution logic both
during the initial AST pass and during the second conversion pass.

Update demo C++ bindings example for new bindings

Gen bindings with rustc --pretty=expanded instead of reading files

Instead of walking individual rust files and reading the AST from
those, we instead call
`RUSTC_BOOTSTRAP=1 cargo rustc --profile=check -- -Zunstable-options --pretty=expanded`
and let it create one giant lib.rs which we can parse as a whole.
This allows us to parse a post-macro crate, working with structs
and functions created inside macros just fine. It does require
handling a few things that we didn't previously, most notably Clone
via `impl ::core::clone::Clone` blocks instead of just looking for
`#![derive(Clone)]`.

This ends up resolving a few types slightly differently, resulting
in different bindings, but only in ways which don't impact the
runtime.

[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

Rename output descriptor types for some clarity

Both Miron and Val suggested naming tweaks in their reviews, so
clarifying things some would be good.

Clarify docs on revocation_pubkey in DynamicP2WSHOutputDescriptor

Drop stale and cleanup TODO entries in keysinterface

Switch to calling new KeysManager output-spending fn in tests

Add util fn for creating a Transaction from spendable outputs

This adds a utility method, `KeysManager::spend_spendable_outputs`,
which constructs a Transaction from a given set of
`SpendableOutputDescriptor`s, deriving relevant keys as needed.

It also adds methods which can sign individual inputs where
channel-specific key derivation is required to
`InMemoryChannelKeys`, making it easy to sign transaction inputs
when a custom `KeysInterface` is used with `InMemoryChannelKeys`.

Add utility function to add a change output to a transaction

Drop dup txn in test_dynamic_spendable_outputs_local_htlc_success_tx

Previously, test_dynamic_spendable_outputs_local_htlc_success_tx
called connect_block with two identical transactions, which
resulted in duplicate SpendableOutputs Events back-to-back. This
is a test issue as such a block_connected call represents an
invalid block.

Drop unused Network argument to KeysManager::new().

KeyManager::new() took a bitcoin::Network parameter which needs to
be passed to the BIP 32 Extended Key constructor, but because we
never write out the BIP 32 serialization, it isn't used. Instead,
we just pass a dummy value into `ExtendedPrivKey`, dropping the
unused argument to KeysManager::new().

f fix typos val caught

Struct-ify SpendableOutputDescriptor entries relevant to channels

Both SpendableOutputDescriptor::DynamicOutputP2WSH and
SpendableOutputDescriptor::StaticOutputCounterpartyPayment are
relevant only in the context of a given channel, making them
candidates for being passed into helper functions in
`InMemoryChannelKeys`. This moves them into their own structs so
that they can later be used standalone.

[tests] Correct witness len calc in StaticOutputCounterpartyPayment

We previously counted 35 bytes for a length + public key, but in
reality they are never larger than 34 bytes - 33 for the key and 1
for the push length.

Merge pull request #786 from TheBlueMatt/2021-02-chansigner-util

Expand documentation and fields in SpendableOutputDescriptors

Merge pull request #797 from TheBlueMatt/2021-02-no-addr-order

Drop address ordering enforcement in NodeAnnouncement deser

Merge pull request #798 from TheBlueMatt/2021-02-route-bench

Fetch network graph cache and run benchmarks on CI

Add a trivial benchmark of calculating routes on today's graph

Sadly rust upstream never really figured out the benchmark story,
and it looks like the API we use here may not be long for this
world. Luckily, we can switch to criterion with largely the same
API if that happens before upstream finishes ongoing work with the
custom test framework stuff.

Sadly, it requires fetching the current network graph, which I did
using Val's route-testing script written to test the MPP router.

Allow gossip messages to have 1KB of uninterpreted data and relay

Drop trailing semicolons which rustc nightly generates warnings for

Adapt C++ bindings demo to new API and keys (new funding tx)

Update auto-generated bindings

Slightly expand documentation on KeysInterface

Specifically, this notes when methods can or can not return the
same value on each call.

Expand documentation and fields in SpendableOutputDescriptors

This adds a channel_value_satoshis field to
SpendableOutputDescriptors as it is required to recreate our
InMemoryChannelKeys. It also slightly expands documentation.

Swap key_derivation_params (u64, u64) for channel_keys_id [u8; 32]

Instead of `key_derivation_params` being a rather strange type, we
call it `channel_keys_id` and give it a generic 32 byte array. This
should be much clearer for users and also more flexible.

Drop address ordering enforcement in NodeAnnouncement deser

It seems many other nodes never bothered to enforce these
requirements, so there's little reason that we should either.

cc https://github.com/lightningnetwork/lightning-rfc/pull/842

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