[lightning-net-tokio] Fix race-y unwrap fetching peer socket address

I recently saw the following panic on one of my test nodes:

```
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()`
    on an `Err` value: Os { code: 107, kind: NotConnected, message:
    "Transport endpoint is not connected" }',
    rust-lightning/lightning-net-tokio/src/lib.rs:250:38
```

Presumably what happened is somehow the connection was closed in
between us accepting it and us going to start processing it. While
this is a somewhat surprising race, its clearly reachable. The fix
proposed here is quite trivial - simply don't `unwrap` trying to
fetch our peer's socket address, instead treat the peer address as
`None` and discover the disconnection later when we go to read.

Merge pull request #1378 from ViktorTigerstrom/2022-03-include-htlc-min-max

Include htlc min/max for ChannelDetails and ChannelCounterparty

Add htlc min/max to create invoice functions

Add outbound min/max to `ChannelCounterparty`

Merge pull request #1417 from johncantrell97/generic-persist

add `KVStorePersister` trait and blanket implementations of `Persist` and `Persister` for any type that implements `KVStorePersister`

implement Persist and Persister with generic KVStorePersister trait

Merge pull request #1419 from atalw/2022-03-paymentforwarded-event

Expose more info in `PaymentForwarded` event

Add `source_channel_id` in `PaymentForwarded` event

Add inbound htlc min/max to `ChannelDetails`

Merge pull request #1414 from ViktorTigerstrom/2022-04-default-to-tlv-onions

Default to BOLT 4 tlv payload format onions

Merge pull request #1422 from dunxen/2022-04-invoice-expiry

Add expiry to phantom invoice utility functions

Add expiry to inbound payment util functions

Add tests for defaulting to creating tlv onions

Merge pull request #1404 from TheBlueMatt/2022-04-buf-writes

Pipe filesystem writes in `lightning-persister` through `BufWriter`

Merge pull request #1423 from jkczyz/2022-04-dyn-block-source

Allow `&dyn BlockSource` in `lightning-block-sync`

Remove unnecessary lifetime bound

Remove mut in lightning-block-sync tests

Allow &dyn BlockSource in lightning-block-sync

Update lightning-block-sync's init and poll modules to support &dyn
BlockSource such that the BlockSource can be determined at runtime.

Pass `PaymentParameters` in `get_route_and_payment_hash`

Default to creating BOLT4 tlv payload format onions

Default to creating tlv onions for nodes for which we haven't received
any features through node announcements or which aren't in the
`network_graph`, and where no other features are known such as invoice
features nor features in the init msg for nodes we have channels to.

Merge pull request #1384 from valentinewallace/2022-03-chanmanless-phantom-invoices

Merge pull request #1406 from TheBlueMatt/2022-04-scorer-precision

[RFC] Expand the precision of our log10 lookup tables + add precision

Expose methods for ChannelManager-less phantom invoice generation

Merge pull request #1412 from lightningdevkit/dependabot/github_actions/codecov/codecov-action-3

Bump codecov/codecov-action from 2 to 3

Lower-bound the log approximation and stop using it > ~98.5%

When we start getting a numerator and divisor particularly close to
each other, the log approximation starts to get very noisy. In
order to avoid applying scores that are basically noise (and can
range upwards of 2x the default per-hop penalty), simply consider
such cases as having a success probability of 100%.

Expand the precision of our log10 lookup tables + add precision

When we send values over channels of rather substantial size, the
imprecision of our log lookup tables creates a rather substantial
non-linearity between values that round up or down one bit.

For example, with the default scoring values, sending 100k sats
over channels with 1m, 2m, 3m, and 4m sats of capacity score
rather drastically differently: 3645, 2512, 500, and 1442 msat.

Here we expand the precision of our log lookup tables rather
substantially by: (a) making the multiplier 2048 instead of 1024,
which still fits inside a u16, and (b) quadrupling the size of the
lookup table to look at the top 6 bits after the most-significant
bit of an input instead of the top 4.

This makes the scores of the same channels substantially more
linear, with values of 3613, 1977, 1474, and 1223 msat.

The same channels would be scored at 3611, 1972, 1464, and 1216
msat with a non-approximating scorer.

Merge pull request #1307 from jkczyz/2022-02-block-source-self-ref

Immutable BlockSource interface

Bump codecov/codecov-action from 2 to 3

Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 2 to 3.
- [Release notes](https://github.com/codecov/codecov-action/releases)
- [Changelog](https://github.com/codecov/codecov-action/blob/master/CHANGELOG.md)
- [Commits](https://github.com/codecov/codecov-action/compare/v2...v3)

---
updated-dependencies:
- dependency-name: codecov/codecov-action
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Merge pull request #1409 from TheBlueMatt/2022-04-bindings-invoice-ders

Move lightning-invoice deser errors to lib.rs instead of `pub use`

Move lightning-invoice deser errors to lib.rs instead of `pub use`

Having public types in a private module is somewhat awkward from a
readability standpoint, but, more importantly, the bindings logic
has a relatively rough go of converting them - it doesn't implement
`pub use` as its "implement this function" logic is all within the
context of a module. We'd need to keep a set of re-exported things
to implement them when parsing modules...or we could just move two
enums from `de.rs` to `lib.rs` here, which is substantially less
work.

Immutable BlockSource interface

Querying a BlockSource is a logically immutable operation. Use non-mut
references in its interface to reflect this, which allows for users to
hold multiple references if desired.

Pipe filesystem writes in `lightning-persister` through `BufWriter`

We generally make no effort to ensure all writes are buffered in
lower-level objects, so wrapping write calls in `BufWriter` may
substantially improve performance in some cases. This is especially
important now that we block the sample node exit until the
`NetworkGraph` has been written out, which includes many small-ish
writes.

With this change, shutdown of the sample node on a relatively
underpowered device went from 15-30 seconds of CPU time to a second
or two, plus IO sync time.

Add a test which demonstrates scores for some realistic payments

Merge pull request #1397 from jkczyz/2022-03-release-0.0.106

Cut 0.0.106

Bump crate versions to 0.0.106/invoice 0.14

Update CHANGELOG for 0.0.106

Merge pull request #1399 from jkczyz/2022-03-scoring-tweaks

ProbabilisticScorer improvements

Add an amount penalty to ProbabilisticScorer

The cost of large payments tends to be dominated by the channel fees. To
avoid this, add an amount penalty to ProbabilisticScorer with a user
configurable multiplier. The multiplier is applied for every 2^20th of
the amount weighted by the negative log10 of the channel's success
probability for the payment.

Avoid retrying over recently failed channels

In ProbabilisticScorer, the channel liquidity balance is reduced
whenever a payment fails at the corresponding channel. The payment may
still be retried through the channel, however, because the liquidity
penalty is capped. Use u64::max_value instead in this situation to avoid
retrying over the same path. This effectively makes u64::max_value the
penalty for amounts exceeding the upper bound, as well.

As an edge case, avoid using u64::max_value on attempts where the amount
is equal to the effective capacity, which may be the HTLC maximum when
the channel capacity is unknown.

Merge pull request #1398 from jkczyz/2022-03-middle-hop-fix

Router fixes

Don't consider a path as having hit HTLC-min if it isn't sufficient

During the first pass of path finding, we seek a single path with the
exact payment amount, and only seek additional paths if (a) no single
path can carry the entire balance of the payment or (b) we found a good
path, but along the way we found candidate paths with the potential to
result in a lower total fee. This commit fixes the behavior of (b) -- we
were previously considering some paths to be candidates for a lower fee
when in fact they never would have worked. This caused us to re-run
Dijkstra's when it might not have been beneficial.

Select best route by lowest total cost

Selecting only by fees rather than cost (fees plus penalty) may result
in preferring higher cost routes over lower cost ones.

Correctly pick middle hop to victimize

For even-length paths, preferring a later hop avoids overly limiting the
possible paths on the next iteration.

Fix build warnings without grind_signatures

Merge pull request #1376 from jurvis/jurvis/persist-networkgraph

Persist NetworkGraph on removal of stale channels

Use common Persister for persistence tests

Move expected_bytes to check_persisted_data! macro

Add NetworkGraph persistence

Instead of creating a separate trait for persisting NetworkGraph, use and rename the existing ChannelManagerPersister to handle them both. persist_graph is then called on removal of stale channels and on exit.

Merge pull request #1351 from TheBlueMatt/2022-03-scid-privacy

Implement the SCIDAlias Channel Type and provide SCID Privacy

Move inbound_payment module into its own file

As part of preparing to expose some of its methods as pub for ChannelManager-less
phantom invoice generation.

Pure code move of the module + the addition of module-level documentation

Add notes about SCID alias rotation to `ChannelDetails` docs

Drop the `Writeable::encode_with_len` method in non-test buidls

There's not a lot of reason to keep it given its used in one place
outside of tests, and this lets us clean up some of the byte_utils
calls that are still lying around.

Use the correct SCID when failing HTLCs to aliased channels

When we fail an HTLC which was destined for a channel that the HTLC
sender didn't know the real SCID for, we should ensure we continue
to use the alias in the channel_update we provide them. Otherwise
we will leak the channel's real SCID to HTLC senders.

Make all callsites to `get_channel_update_for_unicast` fallible

This reduces unwraps in channelmanager by a good bit, providing
robustness for the upcoming 0conf changes which allow SCIDs to be
missing after a channel is in use, making
`get_channel_update_for_unicast` more fallible.

This also serves as a useful refactor for the next commit,
consolidating the channel_update creation sites which are changed
in the next commit.

Add simple tests for our SCIDAlias implementation and negotiation

Negotiate `scid_alias` for private channels based on a new config

Because negotiating `scid_alias` for all of our channels will cause
us to create channels which LDK versions prior to 0.0.106 do not
understand, we disable `scid_alias` negotiation by default.

Add support for the SCIDAlias feature bit in incoming channels

This does not, however, ever send the scid_alias feature bit for
outgoing channels, as that would cause the immediately prior
version of LDK to be unable to read channel data.

Expose chan type in `Event::OpenChannelRequest` & `ChannelDetails`

As we add new supported channel types, inbound channels which use
new features may cause backwards-compatibility issues for clients.
If a new channel is opened using new features while a client still
wishes to ensure support for downgrading to a previous version of
LDK, that new channel may cause the `ChannelManager` to fail
deserialization due to unsupported feature flags.

By exposing the channel type flags to the user in channel requests,
users wishing to support downgrading to previous versions of LDK
can reject channels which use channel features which previous
versions of LDK do not understand.

Bump `check_commits` CI job rustc to 1.57

1.51 (and other earlier versions of `rustc`) appear to refuse to
accept our documentation links due to a bogus failure to resolve
`ChannelTypeFeatures::supports_scid_privacy`.

Merge pull request #1388 from lightning-signer/2022-03-grind

Merge pull request #1375 from jkczyz/2022-03-scorer-followup

ProbabilisticScorer optimizations

Merge pull request #1382 from TheBlueMatt/2022-03-gossip-queries-sucks

Fix gossip using `gossip_timestamp_filter` instead of queries

Add low_r signature grinding

default on, can be turned off via a feature gate

Merge pull request #1381 from shamardy/2022-03-set-inbound-user-chan-id

Add `user_channel_id` to `accept_inbound_channel` method

Fix gossip using `gossip_timestamp_filter` instead of queries

See large comment added for more details

Increase default liquidity_penalty_multiplier_msat

Using a larger multiplier gives more reasonable penalties for larger
success probabilities.

Move max penalty cap in ProbabilisticScorer

This reduce a branch in the 0 and u6::max_value cases.

Fix overflow in ProbabilisticScorer

When a routing hint is given in an invoice, the effective capacity of
the channel is assumed to be infinite (i.e., u64::max_value) if the hop
is private. Adding 1 to this in the success probability calculation will
cause an overflow and ultimately an `index out of bounds panic` in
log10_times_1024. This was not an issue with using log10 because the use
of f64 would give infinite which casts to 0 for u64.

Add a base penalty to ProbabilisticScorer

ProbabilisticScorer tends to prefer longer routes to shorter ones. Make
the default scoring behavior include a customizable base penalty to
avoid longer routes.

Don't serialize FixedPenaltyScorer parameters

Serializing scorer parameters makes it difficult to experiment with
different settings.

set user_channel_id in accept_inbound_channel fn

fix docs

edit user_channel_id docs for Event::ChannelClosed

review fixes

Merge pull request #1359 from tnull/2022-03-real-random-shuffle

Randomize candidate paths during route selection.

Merge pull request #1380 from TheBlueMatt/2022-03-skip-redundant-sig-checks

Skip `channel_update` signature checks if we have a newer state

Skip `channel_update` signature checks if we have a newer state

`channel_update` messages already have their signatures checked
with the network graph write lock held, so there's no reason to
check the signatures before doing other quicker checks first,
including checking if we're already aware of a newer update for the
channel.

This reduces common-case CPU usage as `channel_update`s are sent
rather liberally over the p2p network to gossip them.

Merge pull request #1058 from TheBlueMatt/2021-08-fail-claimed-dust-htlc

Add a further test of HTLC failure after a claim occurrs.

Minor refactor for sort / add, and some nits.

- `sort_by_key` to `sort_unstable_by_key`
- `checked_add() .. max_value()` to `saturating_add()`
- Some typos and nits

Randomize candidate paths during route selection.

Add a further test of HTLC failure after a claim occurrs.

This adds a further test of 7e78fa660cec8a73286c94c1073ee588140e7a01
which I had lying around in my TODO list for a while.

Merge pull request #1370 from TheBlueMatt/2022-03-pref-first-hop-chans

Avoid needless MPP on multiple channels to the same first-hop

Merge pull request #1360 from tnull/2022-03-loopless-random-walks

Avoid looping CLTV shadow routes.

Merge pull request #1326 from Psycho-Pirate/peers

Added option to send remote IP to peers

Avoid needless MPP on multiple channels to the same first-hop

When we have many channels to the same first-hop, many of which do
not have sufficient balance to make the requested payment, but when
some do, instead of simply using the available channel balance we
may switch to MPP, potentially with many, many paths.

Instead, we should seek to use the smallest channel which can
easily handle the requested payment, which we do here by sorting
the first_hops in our router before beginning the graph search.

Note that the "real" fix for this should be to instead decide which
channel to use at HTLC-send time, as most other nodes do during
relay, but this provides a minimal fix without needing to do the
rather-large work of refactoring our HTLC send+relay pipelines.

Issues with overly-aggressive MPP on many channels were reported by
Cash App.

Avoid looping CLTV shadow routes.

Merge pull request #1374 from TheBlueMatt/2022-03-bindings-cleanups

Trivial Bindings Cleanups

Argument added in lightning-net-tokio/src/lib.rs and comments updated

added network address in methods, filter_address function with tests and updated documentation

Merge pull request #1353 from dunxen/2022-03-mpp-receive-timeout

Add MPP receive timeout handling

Merge pull request #1373 from lightningdevkit/dependabot/github_actions/actions/cache-3

Bump actions/cache from 2 to 3

Merge pull request #1368 from TheBlueMatt/2022-03-fix-post-start-sync

Send a gossip_timestamp_filter on connect to enable gossip sync

Add MPP receive timeout handling

Merge pull request #1352 from TheBlueMatt/2022-03-debug-rwlock

Implement lockorder checking on RwLocks in debug_sync

Use `impl<bounds>` instead of a `where` clause to help bindings

Tag some type aliases with `(C-not exported)`

Type aliases are now more robustly being exported in the C bindings
generator, which requires ensuring we don't include some type
aliases which make no sense in bindings.

Bump actions/cache from 2 to 3

Bumps [actions/cache](https://github.com/actions/cache) from 2 to 3.
- [Release notes](https://github.com/actions/cache/releases)
- [Commits](https://github.com/actions/cache/compare/v2...v3)

---
updated-dependencies:
- dependency-name: actions/cache
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Merge pull request #1361 from luizParreira/rust-lightning/issues/1280

Create normal/phantom invoice with description hash

Use the term "lock" for `Mutex`/`RwLock` instead of "mutex"

Implement lockorder checking on RwLocks in debug_sync

Create normal/phantom invoice with description hash

Merge pull request #1363 from TheBlueMatt/2022-03-tx-conf-ordering-lock-delay

Generate a funding_locked on relevant transactions_confirmed calls

Send a `gossip_timestamp_filter` on connect to enable gossip sync

On connection, if our peer supports gossip queries, and we never
send a `gossip_timestamp_filter`, our peer is supposed to never
send us gossip outside of explicit queries. Thus, we'll end up
always having stale gossip information after the first few
connections we make to peers.

The solution is to send a dummy `gossip_timestamp_filter`
immediately after connecting to peers.