Avoid saturating channels before we split payments

Currently we only opt to split a payment into an MPP if we have
completely and totally used a channel's available capacity (up to
the announced htlc_max or on-chain capacity, whichever is lower).
This is obviously destined to fail as channels are unlikely to have
their full capacity available.

Here we do the minimum viable fix by simply limiting channels to
only using up to a configurable power-of-1/2. We default this new
configuration knob to 1 (1/2 of the channel) so as to avoid a
substantial change but in the future we may consider changing this
to 2 (1/4) or even 3 (1/8).

Merge pull request #1567 from tnull/2022-06-send-probe

Add simple probing API

Add `send_probe` and introduce probing cookies

When we send payment probes, we generate the [`PaymentHash`] based on a
probing cookie secret and a random [`PaymentId`]. This allows us to
discern probes from real payments, without keeping additional state.

Merge pull request #1599 from TheBlueMatt/2022-07-fuzz-warns

Drop unused imports in fuzzing test cases

Drop unused imports in fuzzing test cases

Refactor `max_mpp_path_count` to `max_path_count`

Using this field just for MPP doesn't make sense when it could
intuitively also be used to indicate single-path payments. We therefore
rename `max_mpp_path_count` to `max_path_count` and make sure that a
value of 1 ensures MPP is not even tried.

Merge pull request #1588 from TheBlueMatt/2022-06-ffs-dumb-ser

Do not execute the default_value expr until we need it in TLV deser

Do not execute the default_value expr until we need it in TLV deser

This fixes an insta-panic in `ChannelMonitor` deserialization where
we always `unwrap` a previous value to determine the default value
of a later field. However, because we always ran the `unwrap`
before the previous field is read, we'd always panic.

The fix is rather simple - use a `OptionDeserWrapper` for
`default_value` fields and only fill in the default value if no
value was read while walking the TLV stream.

The only complexity comes from our desire to support
`read_tlv_field` calls that use an explicit field rather than an
`Option` of some sort, which requires some statement which can
assign both an `OptionDeserWrapper<T>` variable and a `T` variable.
We settle on `x = t.into()` and implement `From<T> for
OptionDeserWrapper<T>` which works, though it requires users to
specify types explicitly due to Rust determining expression types
prior to macro execution, completely guessing with no knowlege for
integer expressions (see
https://github.com/rust-lang/rust/issues/91369).

Merge pull request #1586 from TheBlueMatt/2022-06-0.0.109

Fix date on 0.0.109 release notes

Merge pull request #1589 from TheBlueMatt/2022-07-sec-policy

Add security policy with PGP keys

Add security policy with PGP keys

Closes #1246.

Merge pull request #1553 from wvanlint/dns_hostname

Adds DNS hostname to NetAddress

Adds DNS hostname to NetAddress

[fuzz] Update auto-generated target list

[fuzz] Add a ChannelDetails msg target

[fuzz] Take a full struct path in msg gen_target.sh

Fix date on 0.0.109 release notes

We slipped by a day and the PR didn't get updated. NBD, though,
the git tag has the correct date.

Merge pull request #1582 from TheBlueMatt/2022-06-0.0.109

Cut 0.0.109

Bump crate versions to 0.0.109/invoice 0.17

Update contributor list for 0.0.107 to be consistent with 0.0.109

Add 0.0.109 CHANGELOG entry.

Merge pull request #1585 from TheBlueMatt/2022-06-copy_from_slice-sucks

Fix spurious panic on bogus funding txn that confirm and are spent

Fix spurious panic on bogus funding txn that confirm and are spent

In c02b6a3807488e1943d79792c5ac0ee52530b971 we moved the
`payment_preimage` copy from inside the macro which only runs if we
are spending an output we know is an HTLC output to doing it for
any script that matches our expected length. This can panic if an
inbound channel is created with a bogus funding transaction that
has a witness program of the HTLC-Success/-Offered length but which
does not have a second-to-last witness element which is 32 bytes.

Luckily this panic is relatively simple for downstream users to
work around - if an invalid-length-copy panic occurs, simply remove
the ChannelMonitor from the bogus channel on startup and run
without it. Because the channel must be funded by a bogus script in
order to reach this panic, the channel will already have closed by
the time the funding transaction is spent, and there can be no
local funds in such a channel, so removing the `ChannelMonitor`
wholesale is completely safe.

In order to test this we have to disable an in-line assertion that
checks that our transactions match expected scripts which we do by
checking for the specific bogus script that we now use in
`test_invalid_funding_tx`.

Thanks to Eugene Siegel for reporting this issue.

Merge pull request #1583 from TheBlueMatt/2022-06-no-ro-graph

Have `find_route` take a `NetworkGraph` instead of a `ReadOnly` one

Have `find_route` take a `NetworkGraph` instead of a `ReadOnly` one

Because downstream languages are often garbage-collected, having
the user directly allocate a `ReadOnlyNetworkGraph` and pass a
reference to it to `find_route` often results in holding a read
lock long in excess of the `find_route` call. Worse, some languages
(like JavaScript) tend to only garbage collect when other code is
not running, possibly leading to deadlocks.

Merge pull request #1564 from TheBlueMatt/2022-06-panic-on-behind

Panic if we're running with outdated state instead of force-closing

Merge pull request #1555 from tnull/2022-06-prefer-small-htlc-max

Add anti-probing penalty to `ProbabilisticScorer`

Add anti-probing penalty to `ProbabilisticScorer`

Currently, channel balances may be rather easily discovered through
probing. This however poses a privacy risk, since the analysis of
balance changes over adjacent channels could in the worst case empower an adversary to
mount an end-to-end deanonymization attack, i.e., track who payed whom.

The penalty added here is applied so we prefer nodes with a smaller `htlc_maximum_msat`, which makes
balance discovery attacks harder to execute. As this improves privacy network-wide, we
treat such nodes preferentially and hence create an incentive to restrict
`htlc_maximum_msat`.

Panic if we're running with outdated state instead of force-closing

When we receive a `channel_reestablish` with a `data_loss_protect`
that proves we're running with a stale state, instead of
force-closing the channel, we immediately panic. This lines up with
our refusal to run if we find a `ChannelMonitor` which is stale
compared to our `ChannelManager` during `ChannelManager`
deserialization. Ultimately both are an indication of the same
thing - that the API requirements on `chain::Watch` were violated.

In the "running with outdated state but ChannelMonitor(s) and
ChannelManager lined up" case specifically its likely we're running
off of an old backup, in which case connecting to peers with
channels still live is explicitly dangerous. That said, because
this could be an operator error that is correctable, panicing
instead of force-closing may allow for normal operation again in
the future (cc #1207).

In any case, we provide instructions in the panic message for how
to force-close channels prior to peer connection, as well as a note
on how to broadcast the latest state if users are willing to take
the risk.

Note that this is still somewhat unsafe until we resolve #1563.

Add ChannelManager methods to force close without broadcasting

If a user restores from a backup that they know is stale, they'd
like to force-close all of their channels (or at least the ones
they know are stale) *without* broadcasting the latest state,
asking their peers to do so instead. This simply adds methods to do
so, renaming the existing `force_close_channel` and
`force_close_all_channels` methods to disambiguate further.

Merge pull request #1550 from tnull/2022-06-scorer-banlist

Allow nodes to be avoided during pathfinding

Allow nodes to be avoided during pathfinding

Users may want to - for whatever reasons - prevent payments to be routed
over certain nodes. This change therefore allows to add `NodeId`s to a
list of banned nodes, which then will be avoided during path finding.

Merge pull request #1518 from valentinewallace/2022-06-OMs-prefactor

Onion messages v1 pre-refactor

Enable simultaneous deserialization+decryption of a ChaChaPoly stream

In the upcoming onion messages PR, this will allow us to avoid decrypting onion
message encrypted data in an intermediate Vec before decoding it. Instead we
decrypt and decode it at the same time using this new ChaChaPolyReadAdapter object.

In doing so, we need to adapt the decode_tlv_stream macro such that it will
decode a LengthReadableArgs, which is a new trait as well. This trait is
necessary because ChaChaPoly needs to know the total length ahead of time to
separate out the tag at the end.

Merge pull request #1556 from danielgranhao/2022-06-improve-docs

Clarify description of get_node_secret() method

chacha20poly1305: enable simultaneous writing+encryption

In the upcoming onion messages PR, this will allow us to avoid encoding onion
message encrypted data into an intermediate Vec before encrypting it.  Instead
we encode and encrypt at the same time using this new ChaChaPolyWriteAdapter object.

Merge pull request #1486 from TheBlueMatt/2022-05-revoked-txn-edge-cases

Fix two edge cases in handling of counterparty revoked commitment txn

Change description of get_node_secret()

Merge pull request #1548 from NicolaLS/serde-module

add feature for Invoice ser/de

Don't fail HTLCs in revoked commitment txn until we spend them

When we see a counterparty revoked commitment transaction on-chain
we shouldn't immediately queue up HTLCs present in it for
resolution until we have spent the HTLC outputs in some kind of
claim transaction.

In order to do so, we first have to change the
`fail_unbroadcast_htlcs!()` call to provide it with the HTLCs which
are present in the (revoked) commitment transaction which was
broadcast. However, this is not sufficient - because all of those
HTLCs had their `HTLCSource` removed when the commitment
transaction was revoked, we also have to update
`fail_unbroadcast_htlcs` to check the payment hash and amount when
the `HTLCSource` is `None`.

Somewhat surprisingly, several tests actually explicitly tested for
the old behavior, which required amending to pass with the new
changes.

Finally, this adds a debug assertion when writing `ChannelMonitor`s
to ensure `HTLCSource`s do not leak.

Merge pull request #1527 from wpaulino/update-htlc-relay-policy

Expose API to update a channel's ChannelConfig

Use new Channel::update_config method to update base fee in test

Allow forwarding HTLCs that were constructed for previous config

This is mostly motivated by the fact that payments may happen while the
latest `ChannelUpdate` indicating our new `ChannelConfig` is still
propagating throughout the network. By temporarily allowing the previous
config, we can help reduce payment failures across the network.

Track previous ChannelConfig and expire after enough ticks

We do this to prevent payment failures while the `ChannelUpdate` for the
new `ChannelConfig` still propagates throughout the network. In a follow
up commit, we'll honor forwarding HTLCs that were constructed based on
either the previous or current `ChannelConfig`.

To handle expiration (when we should stop allowing the previous config),
we rely on the ChannelManager's `timer_tick_occurred` method. After
enough ticks, the previous config is cleared from memory, and only the
current config applies moving forward.

Expose API to update a channel's ChannelConfig

A new `update_channel_config` method is exposed on the `ChannelManger`
to update the `ChannelConfig` for a set of channels atomically. New
`ChannelUpdate` events are generated for each eligible channel.

Note that as currently implemented, a buggy and/or
auto-policy-management client could spam the network with updates as
there is no rate-limiting in place. This could already be done with
`broadcast_node_announcement`, though users are less inclined to update
that as frequently as its data is mostly static.

Expose ChannelConfig within ChannelDetails

As we prepare to expose an API to update a channel's ChannelConfig,
we'll also want to expose this struct to consumers such that they have
insights into the current ChannelConfig applied for each channel.

add optional dependency on serde to implement serialize/deserialize for invoice

Merge pull request #1549 from tnull/2022-06-scorer-query-interface

Provide simple interface to query estimated min/max liquidity

Provide simple interface to query est. liquidity

onion_utils: add next_hop_packet_pubkey method

To get the next hop's packet's pubkey. This will be used to DRY onion message
forwarding in the upcoming Onion Messages PR #1503

Merge pull request #1532 from ariard/2022-06-scaleup-far-away

Scale up CLTV_FAR_FAR_AWAY to 2 weeks of blocks

Scale up CLTV_FAR_FAR_AWAY to 2 weeks of blocks

Merge pull request #1544 from jkczyz/2022-06-node-alias

Define `NodeAlias` struct and `Display` impl

Merge pull request #1531 from ariard/2022-06-fee-sniping

Funding_tx: add anti-fee sniping recommendation and check if final

Define NodeAlias struct and Display impl

Provide a wrapper struct for 32-byte node aliases, which implements
Display for printing. Support the UTF-8 character encoding, but replace
control characters and terminate at the first null character. Fall back
to ASCII if the byte sequence is an invalid encoding.

Correct handling of reorg'd-out revoked counterparty transactions

Previously, while processing a confirmed revoked counterparty
commitment transaction, we'd populate `OnchainEvent`s for live
HTLCs with a `txid` source of the txid of the latest counterparty
commitment transactions, not the confirmed revoked one. This meant
that, if the user is using `transaction_unconfirmed` to notify us
of reorg information, we'd end up not removing the entry if the
revoked commitment transaction was reorg'd out. This would
ultimately cause us to spuriously resolve the HTLC(s) as the chain
advanced, even though we were doing so based on a now-reorged-out
transaction.

Luckily the fix is simple - set the correct txid in the
`OnchainEventEntry`. We also take this opportunity to update
logging in a few places with the txid of the transaction causing an
event.

Merge pull request #1541 from jkczyz/2022-06-nit-follow-ups

Recommend funding_tx to apply anti-fee sniping

Check if funding transaction is final for propagation

If the funding transaction is timelocked beyond the next block of
our best known chain tip, return an APIError instead of silently
failing at broadcast attempt.

Merge pull request #1540 from wpaulino/rename-config-fields

Remove unnecessary identifiers from match pattern

Replace Arc with reference in some tests

Fix grammar in BackgroundProcessor::start docs

Rename UserConfig and LegacyChannelConfig fields

The current names aren't very clear to what each field represents, this
commit aims to improve that.

Merge pull request #1526 from tnull/2022-06-fix-minimal-value-contrib

Fix per-path minimal value contribution during route finding

Add failure test cases for `max_mpp_path_count`.

Fix min. contrib. depending on `max_mpp_path_count`

Merge pull request #1514 from mattfaltyn/issue438

Merge pull request #1529 from wpaulino/move-channel-config-static-fields

Move ChannelConfig static fields to ChannelHandshakeConfig

Document better optional features

Merge pull request #1535 from TheBlueMatt/2022-06-108-ugh

Cut 0.0.108

Update crate versions to 0.0.108/invoice 0.16

Update CHANGELOG for 0.0.108

Merge pull request #1534 from tnull/2022-06-check-release-build

Check release build in CI

Check release build profile in CI

So far, CI did not check the code in the `release` build profile, which
could result in some things not getting caught. To fix this, we now
implement a new CI job that runs checks in the `release` profile.

Switch to stable toolchain.

Merge pull request #1533 from lexe-tech/fix-release

Fix `lightning-background-processor` release build

Fix lightning-background-processor release build

Introduce LegacyChannelConfig to remain backwards compatible

ChannelConfig now has its static fields removed. We introduce a new
LegacyChannelConfig struct that maintains the serialization as
previously defined by ChannelConfig to remain backwards compatible with
clients running 0.0.107 and earlier.

Move commit_upfront_shutdown_pubkey to ChannelHandshakeConfig

As like the previous commit, `commit_upfront_shutdown_pubkey` is another
static field that cannot change after the initial channel handshake. We
therefore move it out from its existing place in `ChannelConfig`.

Move announced_channel to ChannelHandshakeConfig

In the near future, we plan to allow users to update their
`ChannelConfig` after the initial channel handshake. In order to reuse
the same struct and expose it to users, we opt to move out all static
fields that cannot be updated after the initial channel handshake.

Merge pull request #1496 from TheBlueMatt/2022-05-macro-function-bonus

Make `expect_payment_failed_conditions` a function

Make `expect_payment_failed_conditions` a function

This reduces macro generated code in tests a good bit, and moves us
one step further away from using macros everywhere when we don't
need to.

Merge pull request #1513 from TheBlueMatt/2022-06-fix-fuzz-nonbug

Do not panic on early tx broadcasts in fuzzing

Merge pull request #1524 from ViktorTigerstrom/2022-06-update-fail-holding-cell-htlcs-args

Pass `counterparty_node_id` to `fail_holding_cell_htlcs`

Merge pull request #1525 from jkczyz/2022-05-release-0.0.107

Cut 0.0.107

Bump crate versions to 0.0.107/invoice 0.15

Update CHANGELOG for 0.0.107

Pass `peer_node_id` to `fail_holding_cell_htlcs`

Add lightning-rapid-gossip-sync to README

Merge pull request #1517 from jkczyz/2022-06-gossip-sync-enum

Support only one `GossipSync` in `BackgroundProcessor`

Support only one GossipSync in BackgroundProcessor

BackgroundProcessor can take an optional P2PGossipSync and an optional
RapidGossipSync, but doing so may be easy to misuse. Each has a
reference to a NetworkGraph, which could be different between the two,
but only one is actually used.

Instead, allow passing one object wrapped in a GossipSync enum. Also,
fix a bug where the NetworkGraph is not persisted on shutdown if only a
RapidGossipSync is given.

Implement EventHandler for NetworkGraph

Instead of implementing EventHandler for P2PGossipSync, implement it on
NetworkGraph. This allows RapidGossipSync to handle events, too, by
delegating to its NetworkGraph.

Parameterize NetworkGraph with Logger

P2PGossipSync logs before delegating to NetworkGraph in its
EventHandler. In order to share this handling with RapidGossipSync,
NetworkGraph needs to take a logger so that it can implement
EventHandler instead.

Merge pull request #1501 from tnull/2022-05-mention-compat-level

Mention backwards compatibility in CONTRIBUTING.

Move Secp256k1 context to NetworkGraph

P2PGossipSync has a Secp256k1 context field, which it only uses to pass
to NetworkGraph methods. Move the field to NetworkGraph so other callers
don't need to pass in a Secp256k1 context.

Merge pull request #1159 from jkczyz/2021-11-network-gossip

Rename network-related types

Move network_graph.rs to gossip.rs

The routing::network_graph module contains a few structs related to p2p
gossip. So renaming the module to 'gossip' seems more appropriate.

Rename NetGraphMsgHandler to P2PGossipSync

NetGraphMsgHandler implements RoutingMessageHandler to handle gossip
messages defined in BOLT 7 and maintains a view of the network by
updating NetworkGraph. Rename it to P2PGossipSync, which better
describes its purpose, and to contrast with RapidGossipSync.

Rename ChannelClosed to ChannelFailure

A NetworkUpdate indicating ChannelClosed actually corresponds to a
channel failure as described in BOLT 4:

0x2000 (NODE): node failure (otherwise channel)

Rename the enum variant to ChannelFailure and rename NetworkGraph
methods close_channel_from_update and fail_node to channel_failed and
node_failed, respectively.

Update missed references to get_route in docs