Fix two bugs which access the wrong peer's htlc_minimum_msat value

 * Channel::get_counterparty_htlc_minimum_msat() returned
   holder_htlc_minimum_msat, which was obviously incorrect.
 * ChannelManager::get_channel_update set htlc_minimum_msat to
   Channel::get_holder_htlc_minimum_msat(), but the spec explicitly
   states we "MUST set htlc_minimum_msat to the minimum HTLC value
   (in millisatoshi) that the channel peer will accept." This makes
   sense because the reason we're rejecting the HTLC is because our
   counterparty's HTLC minimum value is too small for us to send to
   them, our own HTLC minimum value plays no role. Further, our
   router already expects this - looking at the same directional
   channel info as it does fees.

Finally, we add a test in the existing onion router test cases
which fails if either of the above is incorrect (the second issue
discovered in the process of writing the test).

Move onion failure tests from functional_tests to their own file

They all have a specific structure, so having them in the mess that
is functional_tests isn't really conducive to readability. More
importantly, functional_tests is so big it slows down compilation,
so even dropping a few hundred lines is a win.

Update bindings after merge of #633, #679, #683.

Clarify docs on payment_point slightly

Merge pull request #679 from ariard/2020-08-concurrent-watchtowers

Implement concurrent broadcast tolerance for distributed watchtowers

Merge pull request #696 from TheBlueMatt/2020-09-ci-check-commits

Check each commit at least builds in CI

Check each commit at least builds in CI

Improve PermanentFailure requiremnts documentation

Sources of the failure may be multiple in case of distributed watchtower
deployment. In either case, the channel manager must return a final
update asking to its channel monitor(s) to broadcast the lastest state
available. Revocation secret must not be released for the faultive
channel.

In the future, we may return wider type of failures to take more
fine-grained processing decision (e.g if local disk failure and
redudant remote channel copy available channel may still be processed
forward).

Add test_concurrent_monitor_claim

Watchower Alice receives block 134, broadcasts state X, rejects state Y.
Watchtower Bob accepts state Y, receives blocks 135, broadcasts state Y.
State Y confirms onchain. Alice must be able to claim outputs.

Implement concurrent broadcast tolerance for distributed watchtowers

With a distrbuted watchtowers deployment, where each monitor is plugged
to its own chain view, there is no guarantee that block are going to be
seen in same order. Watchtower may diverge in their acceptance of a
submitted `commitment_signed` update due to a block timing-out a HTLC
and provoking a subset but yet not seen by the other watchtower subset.
Any update reject by one of the watchtower must block offchain coordinator
to move channel state forward and release revocation secret for previous
state.

In this case, we want any watchtower from the rejection subset to still
be able to claim outputs if the concurrent state, has accepted by the
other subset, is confirming. This improve overall watchtower system
fault-tolerance.

This change stores local commitment transaction unconditionally and fail
the update if there is knowledge of an already signed commitment
transaction (ChannelMonitor.local_tx_signed=true).

Merge pull request #684 from bmancini55/gossip_queries

Adding gossip_queries messages and serializations

Adding fuzzers for gossip_queries messages

This commit adds ser/deser fuzzers for five new structs in ln::msgs used
for gossip_queries.

Adding gossip_queries message structs and serialization

This adds the message structs and implements Readable and Writeable
traits for the standard gossip_queries messages.

Merge pull request #633 from ariard/2020-05-rename-keys-var

Rename a's keys as local's keys and b's keys as remote's keys

Cleanup locally-selected-delay

Comment meaning of holder/counterparty

Diverse chan_utils cleanups

Cleanups post-cbindings merge

Fix misusage of holder_selected_contest_delay instead of counterparty
_selected_contest_delay in HolderCommitmentTransaction

Fix old payment_point comment

Overhaul LocalCommitmentTx to new nomenclature

Overhaul ChannelMonitor/OnchainTxHandler to new nomenclature

Change ChannelKeys interface nomenclature to holder/counterparty one

Transaction signing methods are changed from local_/remote_ prefix
to newer holder_/counterparty_ wihout any semantic changes.

Underscore TxCreationKeys ownership

A TxCreationKeys set represents the key which will be embedded in output
scripts of a party's commitment tx state. Among them there is a always
a key belonging to counter-party, the HTLC pubkey. To dissociate
strongly, prefix keys with broadcaster/countersignatory.

A revocation keypair is attributed to the broadcaster as it's used
to punish a fraudulent broadcast while minding that such keypair
derivation method will be always used by countersignatory as it's
its task to enforce punishement thanks to the release secret.

Change variable nomenclature for to_self_delay

To avoid reviewers confusion, rename counterparty_to_self_delay
to counteparty_selected_contest_delay, i.e the justice delay announced
by a channel counterparty restraining our transactions, and to_self_delay
to locally_selected_contest_delay, i.e the justice delay announced by us
restraining counterparty's transactions

We deviate from wider nomenclature by prefixing local data with a
locally_ extension due to the leak of this value in transactions/scripts
builder, where the confusion may happen.

Rename further AcceptChannelData to the new nomenclature.

Change variable nomenclature for Channel fields

Previously most of variable fields relative to data belonging to
our node or counterparty were labeled "local"/"remote". It has been
deemed confusing with regards to transaction construction which is
always done from a "local" viewpoint, even if owner is our counterparty

Merge pull request #688 from TheBlueMatt/2020-09-dev-docs

Add developer guideline notes for C/C++ bindings generation

Add a few more things to gitignore for bindings

Rename lightning C/C++ bindings library to libldk

This should fix #689.

Note that genbindings.sh is really also a test script.

Remove the bindings crate from the root namespace to let it break

Until we get the bindings generation process super stable, let the
bindings get stale with respect to the main repo while still letting
`cargo check` pass.

Add developer guideline notes for C/C++ bindings generation

Change variable nomenclature in chan_utils

Variables should be named according to the script semantic which is
an invariant with regards to generating a local or remote commitment
transaction.

I.e a broadcaster_htlc_key will always guard a HTLC to the party able
to broadcast the computed transactions whereas countersignatory_htlc_key
will guard HTLC to a countersignatory of the commitment transaction.

Merge pull request #618 from TheBlueMatt/2020-05-sample-c-bindings

C/C++ Bindings

Use Debian experimental in CI to match LLVM between rustc and clang

Specify panic = abort in profiles for lightning-c-bindings

Apply -O1 only to tests, not all dev (which is used for bindings)

Add bindings README

Add CI run for bindings generation (though we'll allow it to fail)

LTO in release mode by default, which is really critical for C libs

Update the root Cargo.toml to point to the new subcrate

Add automatically generated C/C++ wrapper bindings

Add all the manually-generated bits for the c-bindings crate

Including:
 * A script to automatically generate all the rest,
 * Cargo.toml and cbindgen.toml,
 * manually-written wrapper types for a few types

Add annotations for things which we cannot (yet) expose

Add tool to read a Rust crate and generate C-compatible wrappers

In general, it maps:
 * Traits to a struct with a void* and a list of function pointers,
   emulating what the compiler will do for a dyn trait anyway,
 * Structs as a struct with a single opaque pointer to the
   underlying type and a flag to indicate ownership. While this is
   a bit less effecient than just a direct pointer, it neatly lets
   us expose in the public interface the concept of ownership by
   setting a flag in the generated struct.
 * Unit enums as enums with each type copied over and conversion
   functions,
 * Non-unit enums have each field converted back and forth with a
   type flag and a union across all the C-mapped fields.

Remove a few final ::-containing paths in generic args

This cleans upa few last cases of functions/objects which our C
bindings generator doesn't know how to read.

Merge pull request #686 from TheBlueMatt/2020-09-bump-deps

Bump rust-bitcoin and friends

Silence new rustc warning about useless muts

Use rust-bitcoin's new SigHashCache instead of SignatureHashComp's

Thew new API is a bit harder to misuse by taking a reference to the
transaction to require the inputs match the input being signed.

Update to latest upstream rust-bitcoin

Merge pull request #676 from TheBlueMatt/2020-08-c-bindings-cleanups-3

Pre-C-Bindings Cleanups #3

Merge pull request #674 from TheBlueMatt/2020-08-keyif-rand-names

Simplify + clarify random-bytes-fetching from KeysInterface

Add a C-bindings-compatible read lock type for NetworkGraph

In order to calculate a route, it is likely that users need to take
a read()-lock on NetGraphMsgHandler::network_graph. This is not
possible naively from C bindings, as Rust's native RwLock is not
exposed.

Thus, we provide a simple wrapper around the RwLockReadGuard and
expose simple accessor methods.

Rename TxCreationKeys::new to not conflict w/ auto-gen'd C bindings

The C bindings automatically create a _new() function for structs
which contain only pub fields which we know how to map. This
conflicts with the actual TxCreationKeys::new() function, so we
simply rename it to capture its nature as a derivation function.

Give ChannelManagerReadArgs HashMap-of-monitors ownership

Its somewhat awkward that ChannelManagerReadArgs requires a mutable
reference to a HashMap of ChannelMonitors, forcing the callsite to
define a scope for the HashMap which they almost certainly won't use
after deserializing the ChannelManager. Worse, to map the current
version to C bindings, we'd need to also create a HashMap binding,
which is overkill for just this one use.

Instead, we just give the ReadArgs struct ownership of the HashMap
and add a constructor which fills the HashMap for you.

Use ln OutPoints not bitcoin ones in SpendableOutputDescriptors

Lightning OutPoints only have 16 bits to express the output index
instead of Bitcoin's 32 bits, implying that some outputs are
possibly not expressible as lightning OutPoints. However, such
OutPoints can never be hit within the lightning protocol, and must
be on-chain spam sent by a third party wishing to donate us money.
Still, in order to do so, the third party would need to fill nearly
an entire block with garbage, so this case should be relatively
safe.

A new comment in channelmonitor explains the reasoning a bit
further.

Use slices to references not slices of concrete objects in pub API

Because the C bindings maps objects into new structs which contain
only a pointer to the underlying (immovable) Rust type, it cannot
create a list of Rust types which are contiguous in memory. Thus,
in order to allow C clients to call certain Rust functions, we have
to use &[&Type] not &[Type]. This commit fixes this issue for the
get_route function.

Refer to return types by the trait that they're defined via

Instead of using the explicit type which is being returned, refer
to them as Self::AssociatedType, to make clear to the bindings what
type of thing is being returned.

Refer to generic types by importing them instead of a super-mod.

This avoids one case the bindings generation hasn't bothered to
handle by simply importing types that are referred to.

Always refer to Deref types with where clauses instead of direct

This makes it a little easier to write C bindings generation as
we only have to handle one case instead of both.

Reorder struct definitions so that they are in dependency order.

There are a few cases where the upcoming C bindings don't know how
to handle something which depends on something defined later in the
file. Instead of adding another pass to the C bindings generator,
it is much simpler to just reorder structs.

Merge pull request #667 from valentinewallace/remove-channels-chanmon

Remove Channel's ChannelMonitor copy

Remove Channel's ChannelMonitor copy

Add commitment transaction broadcast as a ChannelMonitor event

To do this, we replace get_and_clear_pending_htlcs_updated with
get_and_clear_pending_monitor_events, and which still transmits HTLCUpdates
as before, but now also transmits a new MonitorEvent::CommitmentTxBroadcasted
event when a channel's commitment transaction is broadcasted.

Merge pull request #675 from dspicher/master

Refactor route tests

Refactor route tests

* Splits up the monolithic test into smaller unit tests

* Factors out helpers for graph setup

* Changes `id_to_feature_flags` to be a function, there was no
reason why it had to be a macro

* Activates a previously commented-out test that checks for
the failure case in `disable_node_test`

Simplify + clarify random-bytes-fetching from KeysInterface

Due to a desire to be able to override temporary channel IDs and
onion keys, KeysInterface had two separate fetch-random-32-bytes
interfaces - an onion-key specific version which fetched 2 random
32 byte strings and a temporary-channel-id specific version.

It turns out, we never actually need to override both at once (as
creating a new channel and sending an outbound payment are always
separate top-level calls), so there's no reason to add two
functions to the interface when both really do the same thing.

Merge pull request #665 from lightning-signer/pub-messages

Make message fields public

Make message fields public

Merge pull request #671 from valentinewallace/bump-msrv

Bump MSRV to 1.30.0

Bump MSRV to 1.30.0

We wanted to bump to 1.29 to continue to support mrustc bootstrapping, but on 1.29
there's a bug preventing us from compiling the lightning package only, thus parts
of lightning-net-tokio cause a compilation error.

The advantage of bumping the MSRV is an improved borrow checker which should
enable improved code quality, and not having jump through weird hoops sometimes
to get 1.22 working.

Merge pull request #669 from joemphilips/fix_capacity-is-always-zero-bug_in_list_channels

Fix bug in Channel

Merge pull request #668 from lightning-signer/nit

fix typo

Fix bug in Channel

Before this commit, `fn get_inbound_outbound_available_balance_msat` always returns 0.
It is because using `cmp::min` instead of `cmp::max` .

fix typo

Merge pull request #662 from lightning-signer/compat5

Export various fields and structures

check the input shape in LocalCommitmentTransaction.new_missing_local_sig

make LocalCommitmentTransaction constructor public

Allows calling of InMemoryChannelKeys methods

make SimpleManyChannelMonitor.monitors public

export "unsafe_revoked_tx_signing" feature

Allows unsafe signing in dev code, such as functional testing of
justice transactions outside our crate.

Merge pull request #666 from TheBlueMatt/2020-08-license-change

Relicense as dual Apache-2.0 + MIT

Relicense as dual Apache-2.0 + MIT

This changes the LICENSE file and adds license headers to most files
to relicense under dual Apache-2.0 and MIT. This is helpful in that
we retain the patent grant issued under Apache-2.0-licensed work,
avoiding some sticky patent issues, while still allowing users who
are more comfortable with the simpler MIT license to use that.

See https://github.com/rust-bitcoin/rust-lightning/issues/659 for
relicensing statements from code authors.

Merge pull request #664 from lightning-signer/tx-creation-keys

Wrap transaction creation keys

nit

Expose TxCreationKeys in LocalCommitmentTransaction via a method

This makes it obvious to signer implementers that the pre-derived keys are a local cache and should not be trusted in a validating signer.

Make TxCreationKeys public and wrap it in PreCalculatedTxCreationKeys

Allows calling of InMemoryChannelKeys methods.

The wrapping makes it obvious to signer implementers that the pre-derived keys are a local cache and should not be trusted in a validating signer.

Merge pull request #640 from valentinewallace/test-holding-cell-edge-case

Fail back HTLCs that fail to be freed from the holding cell

Holding cell: if we fail to free an HTLC, fail it backwards

Plus add a test.

Merge pull request #663 from TheBlueMatt/2020-08-codecov

Set codecov upload token

Set codecov upload token

Docs seem to indicate this should only be required for private
repos, but we have builds failing claiming this needs to be
specified, so just set it manually.

Merge pull request #658 from lightning-signer/self-delay

ChannelKeys - provide to_self_delay alongside the remote channel pubkeys

ChannelKeys - provide to_self_delay alongside the remote channel pubkeys

In the phase 2 signer, we will construct the commitment transaction inside the signer.
In preparation, provide needed channel related data.

Merge pull request #651 from naumenkogs/2020-06-routing-data-improvements

Routing improvements

Check htlc_maximum_msat on channel update

Store channel capacity if available

Add htlc_maximum_msat field

Update comment for test_msg_hole

Merge pull request #655 from lightning-signer/per-commitment

ChannelKeys - separate commitment revocation from getting the per-commitment point

ChannelKeys - separate commitment revocation from getting the per-commitment point

The commitment secret is sensitive - it can be used by an attacker to
steal funds if the node also signs the same transaction. Therefore,
only release the secret from ChannelKeys when we are revoking a
transaction.

Improve routing announcement test

Fix formatting

Use constant for max msats

Update get_route comment to reflect new parameters

Merge pull request #644 from joemphilips/improve_error_message

Improve error message.

Merge pull request #623 from LNP-BP/feat-msgsizelimit

Making message size limit an exportable constant