Clarify comment on CHECK_CLTV_EXPIRE_SANITY_2 somewhat

Correct MIN_FINAL_CLTV_EXPIRY to match our enforced requirements

Our enforced requirements for HTLC acceptance is that we have at
least HTLC_FAIL_BACK_BUFFER blocks before the HTLC expires. When we
receive an HTLC, the HTLC would be "already expired" if its
`cltv_expiry` is current-block + 1 (ie the next block could
broadcast the commitment transaction and time out the HTLC). From
there, we want an extra HTLC_FAIL_BACK_BUFFER in blocks, plus an
extra block or two to account for any differences in the view of
the current height before send or while the HTLC is transiting the
network.

Increase the CLTV delay required on payments and forwards

This increases the CLTV_CLAIM_BUFFER constant to 18, much better
capturing how long it takes to go on chain to claim payments.
This is also more in line with other clients, and the spec, which
sets the default CLTV delay in invoices to 18.

As a side effect, we have to increase MIN_CLTV_EXPIRY_DELTA as
otherwise as are subject to an attack where someone can hold an
HTLC being forwarded long enough that we *also* close the channel
on which we received the HTLC.

Merge pull request #909 from TheBlueMatt/2021-04-0.0.14

Bump versions to 0.0.14, lightning-invoice 0.5

Merge pull request #901 from jkczyz/2021-04-invoice-feature-semantics

Hide InvoiceFeatures behind InvoiceBuilder API

Merge pull request #845 from ariard/2021-03-hardcode-dust

Switch to a max counterparty's `dust_limit_satoshis` constant

Test feature bit semantics in Invoice::from_signed

Test feature bits in InvoiceBuilder

Add basic_mpp support to InvoiceBuilder

Since InvoiceFeatures are an implementation detail of InvoiceBuilder, an
explicit call is needed to support the basic_mpp feature. Since it is
dependent on the payment_secret feature, conditionally define the
builder's method only when payment_secret has been set.

Hide InvoiceFeatures behind InvoiceBuilder API

Instead of relying on users to set an invoice's features correctly,
enforce the semantics inside InvoiceBuilder. For instance, if the user
sets a PaymentSecret then InvoiceBuilder should ensure the appropriate
feature bits are set. Thus, for this example, the TaggedField
abstraction can be retained while still ensuring BOLT 11 semantics at
the builder abstraction.

Make third HTLC non-dust again in the full_stack_target demo seed

Add bolt2_open_channel_sane_dust_limit

Replace config max counterpary `dust_limit_satoshis` by a constant.

Current Bitcoin Core's policy will reject a p2wsh as a dust if it's
under 330 satoshis. A typical p2wsh output is 43 bytes big to which
Core's `GetDustThreshold()` sums up a minimal spend of 67 bytes (even
if a p2wsh witnessScript might be smaller). `dustRelayFee` is set
to 3000 sat/kb, thus 110 * 3000 / 1000 = 330. As all time-sensitive
outputs are p2wsh, a value of 330 sat is the lower bound desired
to ensure good propagation of transactions. We give a bit margin to
our counterparty and pick up 660 satoshis as an accepted
`dust_limit_satoshis` upper bound.

As this reasoning is tricky and error-prone we hardcode it instead of
letting the user picking up a non-sense value.

Further, this lower bound of 330 sats is also hardcoded as another constant
(MIN_DUST_LIMIT_SATOSHIS) instead of being dynamically computed on
feerate (derive_holder_dust_limit_satoshis`). Reducing risks of
non-propagating transactions in casee of failing fee festimation.

Merge pull request #908 from TheBlueMatt/2021-04-invoice-real-bindings

Minor Tweaks to lightning-invoice for C bindings

Bump versions to 0.0.14, lightning-invoice 0.5

Add a not-exported tag to the Display implementation for RawHrp

RawHrp is already not-exported, so implementations for it should be
as well.

Use explicit import lists instead of glob imports in invoice

While this is less readable, I spent way too long trying to adapt
the bindings generation code to handle glob imports and concluded
it would take refactoring almost the entire import-resolution
logic. While this may be a good refactor to do eventually, its
probably not worth it today.

Sanity test InvoiceFeatures

Require feature var_onion_optin

Feature payment_secret is required and depends on var_onion_optin, so
the latter must also be required.

Skip TaggedField for now as `enum { A(A) }` is broken in Java

... due to A and A aliasing each other.

Set default error type for SignOrCreationError for bindings

The C bindings generator now looks to default generic types as the
way to map a struct or enum parameter. Because SignOrCreationError
is only used directly with an error type of `()`, we set that to
the default and assume no other error types are needed.

Merge pull request #907 from TheBlueMatt/2021-04-merge-conflicts

Fix merge conflicts between #898 and #895.

Deny broken doc links in lightning-invoice as well

Fix merge conflicts between #898 and #895.

Merge pull request #898 from jkczyz/2021-04-invoice-expiry

Require min_final_cltv_expiry in invoices

Merge pull request #895 from valentinewallace/invoice-chanman-utility

Invoice chanman utility

Add utility to create an invoice using the ChannelManager

This also allows the ChannelManager to track information for inbound payments
to check the PaymentSecret on receive.

Move invoice signing behind KeysInterface

Move PaymentPreimage+PaymentHash+PaymentSecret to top-level ln module

Make _test_utils depend on bitcoinconsensus feature

invoice: swap PaymentSecret for ChannelManager's PaymentSecret

Merge pull request #905 from TheBlueMatt/2021-04-mention-invoice-storage-docs

Mention storage req for users with a public invoice generation API

Mention storage req for users with a public invoice generation API

Merge pull request #904 from lightning-signer/no-send-sync

Remove Send and Sync from core crate

Test default invoice field values

Require min_final_cltv_expiry in invoice

Use default for invoice's min_final_cltv_expiry

Use constant for invoice's default expiry value

Remove Send and Sync from core crate

Merge pull request #903 from TheBlueMatt/2021-04-invoice-bindings

Prepare lightning-invoice for export in C

Drop redundant generic parameter bounds on ChainMonitor trait impls

The ChannelSigner bounds are specified both in `impl<>` and in the
`where` clause, which the C bindings generator doesn't like. There
is no reason to have them specified twice.

Add no-export tags for lightning-invoice where we can't map to C

Rename lightning_invoice::Signature to InvoiceSignature

This prevents aliasing the global secp256k1::Signature name in C
bindings and also makes it a little more explicit that the object
is different from other signature types.

Do not return a reference to a u64 in rust-lightning-invoices

There is generally never a reason to return a non-mutable reference
to a u64 vs just copying it, same applies here. It makes the API
slightly less consistent, but is easier to map in bindings and just
makes more sense.

Merge pull request #900 from lightning-signer/init-asap

Send Init message immediately after handshake even if not initiator

Merge pull request #902 from TheBlueMatt/2021-04-fix-fuzz-test

Fix fuzz secp patch by bumping the rust-secp version number in patch

Merge pull request #893 from TheBlueMatt/2021-04-features-chanman

Require payment secrets and track them in ChannelManager

Add a const and docs for the min `min_final_cltv_expiry` we allow

Add some simple tests of payment secret tracking

Fail PendingInboundPayments after their expiry time is reached

Give users who use `get_payment_secret_preimage` the PaymentPreimage

For users who get PaymentPreimages via
`get_payment_secret_preimage`, they need to provide the
PaymentPreimage back in `claim_funds` but they aren't actually
given the preimage anywhere.

This commit gives users the PaymentPreimage in the
`PaymentReceived` event.

Make the PaymentSecret in `PaymentReceived` events non-Optional

Drop the amount parameter to claim_funds

Like the payment_secret parameter, this paramter has been the source
of much confusion, so we just drop it.

Users should prefer to do this check when registering the payment
secret instead of at claim-time.

Drop now-useless PaymentSecret parameters when claiming/failing-back

Add a `user_payment_id` to `get_payment_secret`+`PaymentReceived`

This allows users to store metadata about an invoice at
invoice-generation time and then index into that storage with a
general-purpose id when they call `get_payment_secret`. They will
then be provided the same index when the payment has been received.

Drop dead code for handling non-MPP payments in claim_funds

[fuzz] Always use PaymentSecrets in chanmon_consistency

Req+check payment secrets for inbound payments pre-PaymentReceived

Our current PaymentReceived API is incredibly easy to mis-use -
the "obvious" way to implement a client is to always call
`ChannelManager::claim_funds` in response to a `PaymentReceived`
event. However, users are *required* to check the payment secret
and value against the expected values before claiming in order to
avoid a number of potentially funds-losing attacks.

Instead, if we rely on payment secrets being pre-registered with
the ChannelManager before we receive HTLCs for a payment we can
simply check the payment secrets and never generate
`PaymentReceived` events if they do not match. Further, when the
user knows the value to expect in advance, we can have them
register it as well, allowing us to check it for them.

Other implementations already require payment secrets for inbound
payments, so this shouldn't materially lose compatibility.

Use payment_secrets in all sends in functional tests

This prepares us for requiring payment_secrets for all received
payments, by demonstrating test changes work even prior to the new
requirement.

In order to avoid needing to pipe payment secrets through to
additional places in the claim logic and then removing that
infrastructure once payment secrets are required, we use the new
payment secret storage in ChannelManager to look up the payment
secret for any given pament hash in claim and fail-back functions.
This part of the diff is reverted in the next commit.

Use known InvoiceFeatures for routing in tests

Pipe through PaymentSecrets in tests during payment hash creation

In order to reduce code movement in the next commit, this commit
simply tweaks get_payment_preimage_hash!() and related functions in
functional tests to return a payment secret. Further, we ensure
that we always call get_payment_preimage_hash!() with the node
which will ultimately receive the payment.

DRY the get_route_and_payment_hash!() macro duplicated in tests

Add payment secret and preimage tracking in ChannelManager

This adds support for tracking payment secrets and (optionally)
payment preimages in ChannelManager. This potentially makes client
implementations much simper as they don't have to have external
payment preimage tracking.

This doesn't yet use such tracking anywhere.

Fix fuzz secp patch by bumping the rust-secp version number in patch

Send Init message immediately after handshake even if not initiator

We were waiting for the initiator, but the spec doesn't guarantee that they will send Init first, so we might theoretically wait forever.

Also, lnprototest expects this behavior.

Set payment_secret to required in features flags

Merge pull request #854 from TheBlueMatt/2021-03-fix-lens

Fix serialization expected lengths and check them in test/fuzzing

Use more descriptive names in serialization impl macros

Fix serialization expected lengths and check them in test/fuzzing

Merge pull request #897 from TheBlueMatt/2021-04-fix-ci

Bump MSRV to 1.36

Test lightning-persister on rustc 1.36 as well

Bump MSRV to 1.36.0

Debian is shipping 1.41 on oldstable and rust-bitcoin will likely
move to 1.36 over the coming months, so there's little reason to
wait on this.

cc https://github.com/rust-bitcoin/rust-bitcoin/issues/510

Merge pull request #894 from TheBlueMatt/2021-04-fix-docs

Fix doc resolution in rustc 1.48

Merge pull request #876 from valentinewallace/invoice-features

Invoice features

Add Features feature to invoices.

Merge pull request #890 from TheBlueMatt/2021-04-fix-chan-shutdown-crash

Fix (and test) panic when our counterparty uses a bogus funding tx

Fix (and test) panic when our counterparty uses a bogus funding tx

During the block API refactor, we started calling
Channel::force_shutdown when a channel is closed due to a bogus
funding tx. However, we still set the channel's state to Shutdown
prior to doing so, leading to an assertion in force_shutdown (that
the channel is not already closed).

This removes the state-set call and adds a (long-overdue) test for
this case.

Fixes: 60b962a18ebcf494340ddc001870f8160c625968

Expose Features::from_le_bytes() method

Useful for constructing features objects from raw feature bytes.

Fix indentation in payment_secret function

Fix doc resolution in rustc 1.48

Merge pull request #889 from jkczyz/2021-04-electrum-trait

Define chain::Confirm trait for use by Electrum clients

Drop pub functions for ChainMonitor's Listen impl

Implement chain::Confirm for ChainMonitor

Implement chain::Confirm for relevant structs

Define chain::Confirm trait

Define a separate trait akin to chain::Listen for notifying when
transactions have been confirmed on chain or unconfirmed during a chain
reorganization. Whereas chain::Listen is used for block-oriented chain
sources, chain::Confirm is used for chain sources supplying data for
activity related to transactions and outputs registered via
chain::Filter.

Merge pull request #891 from TheBlueMatt/2021-04-peer_handler_lock

[peer_handler] Take the peers lock before getting messages to send

[peer_handler] Take the peers lock before getting messages to send

Previously, if a user simultaneously called
`PeerHandler::process_events()` from two threads, we'd race, which
ended up sending messages out-of-order in the real world.
Specifically, we first called `get_and_clear_pending_msg_events`,
then take the `peers` lock and push the messages we got into the
sending queue. Two threads may both get some set of messages to
send, but then race each other into the `peers` lock and send the
messages in random order.

Because we already hold the `peers` lock when calling most message
handler functions, we can simply take the lock before calling
`get_and_clear_pending_msg_events`, solving the race.

Merge pull request #887 from valentinewallace/invoice-use-RL-routehint

invoice: swap RouteHop for RouteHint

Test lightning-invoice on 1.30.0

invoice: rename Route to RouteHint (which is more accurate)

Rename RouteHint to RouteHintHop (which is more accurate)

invoice: swap RouteHop for RouteHint

To prevent naming conflicts in bindings

Merge pull request #844 from sr-gi/843-ln-signing

Adds lightning message signing/verification/pk_recovery

Changes zbase32 crate from pub to pub(crate)

Correct license header in zbase32 to match original work

The original work is licensed dual MIT+Apache-2 just like us, so
the license header should not only mention MIT.

Replace spaces with tabs in zbase32.rs

Fix a number of bugs in zbase32 and add a fuzzer which caught them.

Adds lightning message signing/verification/pk_recovery

Merge pull request #886 from TheBlueMatt/2021-04-pub-alias

Make the used-in-pub-interfaces TransactionOutputs type alias pub

Merge pull request #884 from TheBlueMatt/2021-04-bp-bindings

Prep background-processor for bindings inclusion