Move UTXO-lookup into pub utility function from RoutingMsgHandler

This makes the public utility methods in `NetworkGraph` able to do
UTXO lookups ala `NetworkMsgHandler`'s `RoutingMessageHandler`
implementation, slightly simplifying the public interface.

We also take this opportunity to verify signatures before calling
out to UTXO lookups, under the "do actions in order of
cheapest-to-most-expensive to reduce DoS surface" principle.

Finally drop travis entirely.

It seems travis isn't even bothering to spawn our jobs anymore, and
Github CI has been pretty stable, so just drop Travis entirely.

Merge pull request #748 from TheBlueMatt/2020-11-router-fuzzer

Make router_target a bit easier for fuzzers to explore and fix two found bugs

[fuzz] Make router_target a bit easier for fuzzers to explore

It turns out (somewhat obviously) that expecting a fuzzer to
correctly build multiple signatures which verify against multiple
public keys in the same message was a bit too daunting, so we now
skip message signatures in routing messages.

We also take this opportunity to simplify the target itself somewhat,
avoiding reading public keys over and over and instead generating
routes to all the public keys that appeared in messages while running.

Expose manual-update methods in NetworkGraph.

These functions were created but previously not exported, however
they are useful if we want to skip signature checking when accepting
routing messages (which we really should be doing in the routing
fuzzer).

Merge pull request #750 from TheBlueMatt/2020-11-dup-chan-id-crash

Do not generate a channel-closed mon update for never-signed chans

Don't create chan-closed mon update for outbound never-signed chans

Like the previous commit for channel-closed monitor updates for
inbound channels during processing of a funding_created message,
this resolves a more general issue for closing outbound channels
which have sent a funding_created but not yet received a
funding_signed.

This issue was also detected by full_stack_target.

To make similar issues easier to detect in testing and fuzzing, an
additional assertion is added to panic on updates to a channel
monitor before registering it.

Do not generate a channel-closed mon update for never-signed chans

The full_stack_target managed to find a bug where, if we receive
a funding_created message which has a channel_id identical to an
existing channel, we'll end up
 (a) having the monitor update for the new channel fail (due to
     duplicate outpoint),
 (b) creating a monitor update for the new channel as we
     force-close it,
 (c) panicing due to the force-close monitor update is applied to
     the original channel and is considered out-of-order.

Obviously we shouldn't be creating a force-close monitor update for
a channel which can never appear on chain, so we do that here and
add a test which previously failed and checks a few
duplicate-channel-id cases.

[netgraph] Do not allow capacity_sats * 1000 to overflow-panic

In updating the router fuzzer, it discovered that a remote peer can
cause us to overflow while multiplying the channel capacity value.
Since the value should never exceed 21 million BTC, we just add a
check for that.

[router] Fix + test routing via next/last-hop hints only

We had code in the router to support sending a payment via a single
hop across channels exclusively provided by the next-/last-hop hints.
However, in updating the fuzzer, I noted that this case not only
didn't work, but paniced in some cases.

Here, we both fix the panic, as well as write a new test which
ensures we don't break support for such routing in the future.

Merge pull request #749 from TheBlueMatt/2020-11-bindings-clones

Bindings Updates for #681 and more Clones

Use CARGO_PROFILE_RELEASE_LTO to fix bindings build on new cargo

Newer versions of cargo broke `cargo rustc -- -Clto` by passing
`-Cembed-bitcode=no` even in `--release`. Its somewhat unclear why
this is still the case on latest cargo given it broke, at least,
compilation of Firefox, as discovered by Val at [1]. We take the
approach they used there, even though they later walked it back [2]
but the issues noted there, especially in [3] don't seem
particularly concerning in our case.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1640982
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1654465
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1654465#c5

Update auto-generated bindings

Update bindings demo for new ChannelMonitor-update API

[bindings] Update eq/clone trait fns to take object, not this_arg

When a trait is required to implement eq/clone (eg in the case of
`SocketDescriptor`), the generated trait struct contains an
eq/clone function which takes a `this_arg` pointer. Since the trait
object can always be read to get the `this_arg` pointer, there is
no loss of generality to pass the trait object itself, and it
provides a bit more flexibility when the trait could be one of
several implementations (which we use in the Java higher-level
bindings).

derive(Clone) for several pub simple data structs.

There is no reason not to and Clone can be useful especially in the
bindings context.

[bindings] Expose a _clone fn for every enum

This somewhat assumes that every public enum implements clone in
some way, but that is currently the case.

[bindings] Expose a _clone fn for every struct that derive(Clone)s

[bindings] Fix CVecTempl clone operation behavior.

CVecTempl previously called Vec.clone_from_slice() on a
newly-allocated Vec, which immediately panics as
[T].clone_from_slice() requires that the Vec/target slice already
has the same length as the source slice. This should have been
Vec.extend_from_slice() which exhibits the correct behavior.

Update bindings demo for new Transaction::data mut-ness

[bindings] Make Transaction::data *mut instead of *const

When the only reference to the transaction bytes is via
Transaction::data, my understanding of the C const rules is that
it would then be invalid to write to it. While its unlikely this
would ever pose an issue, its not hard to simply make it *mut, so
we do that here.

Update bindings demo for changes from #681 and the Persister trait

[bindings] Support traits with generic arguments (to support #681)

Previously we'd ignored generic arguments in traits, leading to
bogus code generation after the Persister trait was added in #681.

This adds minimal support for it, fixing code generation on latest
upstream.

Merge pull request #753 from TheBlueMatt/2020-11-chanmon_consistency-bits

Tweak and Expand the chanmon_consistency fuzz target

[fuzz] Check that channels don't get stuck in chanmon_consistency

This adds a new command string in the chanmon_consistency fuzzer
which tests that, once all pending HTLCs are settled, at least one
side of a channel can still send funds.

While this should have caught the recent(ish) spec bug where
channels could get stuck, I did not attempt to reproduce said bug
with this patch.

[fuzz] Don't allow HandleError in chanmon_consistency

We should never generate Ignore-action HandleError events anymore

[fuzz] Reduce overuse of macros/Arcs in chanmon_consistency

In previous versions of related commits, the macros in
chanmon_consistency ended up blowing up rustc a bit resulting in
20+GB memory usage and long compile times. Shorter function bodies
by avoiding macros where possible fix this.

[fuzz] Expand the amounts we can send in chanmon_consistency

This should make it a bit easier for the fuzzer to hit any given
balance breakdown during run as well as tweaks the command strings
to be more bit-pattern friendly.

[fuzz] Test chanmon_consistency payment-send errors are sane

Instead of simply always considering a payment-send failure as
acceptable (and aborting fuzzing), we check that a payment send
failure is from a list of errors that we know we can hit, mostly
around maxing out our channel balance.

Critically, we keep going after hitting an error, as there's no
reason channels should get out of sync even if a send fails.

Merge pull request #611 from valentinewallace/fix-missing-htlc-claim

Tell ChannelMonitors about HTLCs fulfilled after channel close

Claim HTLC output on-chain if preimage is recv'd after force-close

If we receive a preimage for an outgoing HTLC that solves an output on a
backwards force-closed channel, we need to claim the output on-chain.

Note that this commit also gets rid of the channel monitor redundantly setting
`self.counterparty_payment_script` in `check_spend_counterparty_transaction`.

Co-authored-by: Antoine Riard <ariard@student.42.fr>
Co-authored-by: Valentine Wallace <vwallace@protonmail.com>

Split channelmonitor's broadcast_by_holder_state

Now callers will separately retrieve the claim requests/
holder revokable script and the new watched holder outputs.
This will be used in the next commit for times when we
need to get holder claim requests, but don't have access to
the holder commitment transaction.

Extend update_monitor logging

Helpful for debugging. I also included the change in the provide_preimage method
signature which will be used in an upcoming commit, because commit-wise it was
easier to combine the changes.

Update monitor with preimage after channel close

If the channel is hitting the chain right as we receive a preimage,
previous to this commit the relevant ChannelMonitor would never
learn of this preimage.

Add prev_channel_outpoint to previous hop data

This will be used in upcoming commits to allow us to update a channel
monitor with a preimage after its channel has closed.

Merge pull request #721 from TheBlueMatt/2020-09-649-bindings

Bindings Updates for #649

Merge pull request #745 from ariard/2020-11-getting-started

Add a Getting Started in CONTRIBUTING.md

Merge pull request #746 from valentinewallace/remove-todo

Remove unnecessary todo

Add a Getting Started

Fix by Steve Lee <moneyball@users.noreply.github.com>

Remove unnecessary todo

The ChannelMonitor already monitors the chain for counterparties
revealing preimages, and will give the HTLCSources back to the
ChannelManager for claiming. Thus it's unnecessary for the ChannelManager
to monitor these HTLCs itself.

See is_resolving_htlc_output:
- if the counterparty broadcasted and then claimed one of the HTLCs we
  offered them, line 2015 is where the ChannelMonitor gives the ChannelManager
  the HTLC source
- if we broadcasted and they claimed an HTLC we offered them, line 2025 is
  where the ChannelMonitor gives the ChannelManager the HTLC source

[bindings] update generated code

Update demo.cpp for new tuple code

[bindings] Un-Box Tuple mapping

Because the C++ wrappers require being able to memset(0) the C
structs to skip free(), we'd previously mapped tuples with two
pointer indirections. However, because all other types already
support memset(0)'ing to disable free() logic, we can skip the
pointer indirections and the behavior is still correct.

[bindings] Fix typo in opaque struct docs found by Val

[bindings] Use the same SipHash keys to make C++ header stable

[bindings] Use enum to describe deref'ing needed for Option<> inners

Update bindings to latest upstream code

Drop the now-unused usizeslice bindings struct

Update bindings demo apps for new code upstream

Move a struct in bindings up to define it before it is used

This is a limitations in the bindings crate, but not one that's
going to be fixed right now.

[bindings] Drop one static-lifetime restriction and check success

In general we should stop enforcing that all lifetimes are static
- we may take references from C and its up to reviewing the diff on
the bindings changes and the user(s) to ensure lifetimes are valid.

Also asserts a success criteria that was missed before.

[bindings] Handle type X = Y aliasing in type resolution

For non-generic type aliases which are meant as convinient aliases
for more complex types, we need to store the aliased type (with all
paths made absolute) and use that in type resolution.

The most code by far is just making all the paths in a type absolute
but its not too bad either.

[bindings] Handle ::-prefixed paths in a few places

[bindings] Remove some uneccessary no-multi-ident path restrictions

[bindings] Avoid guessing whether resolved type is a ref in blocks

In some cases, things which are a Rust Reference (ie slices), we
may still want to map them as a non-reference and need to put a
"mut " in front of the variable name in a function decl. This
worked fine by just checking for the slice case, except that we
are about to add support for type aliases, which no longer match
the naive case.

Instead, we can just have the types module print out the C type and
check if it begins with a '&' to figure out if it is a reference.

[bindings] Support mapping slices which contain tuples (with refs)

New work upstream puts tuples in slices, which is a very reasonable
thing to expect, however we don't know how to generate conversions
for such objects. Making it more complicated, upstream changes also
include references to things inside such slices, which requires
special handling to avoid creating dangling references.

This adds support for converting such objects, noting that slices
need to be converted first into Vecs which own their underlying
objects and then need to map any reference types into references.

[bindings] Give Transaction objects a buffer-is-owned flag.

A lot of our container mapping depends on the `is_owned` flag
which we have for in-crate mapped objects to map references and
non-references into the same container type. Transaction was
mapped to two completely different types (a slice and a Vec type),
which led to a number of edge cases in the bindings generation.
Specifically, I spent a few days trying to map
`[(A, &Transaction)]` properly and came up empty - we map slices
into the same types as Vecs (and rely on the `is_owned` flag to
avoid double-free) and the lack of one for `Transaction` would have
required a special-case in numerous functions.

Instead, we just add a flag in `Transaction` to mirror what we do
for in-crate types and check it before free-ing any underlying
memory.

Note that, sadly, because the c_types objects aren't mapped as a
part of our C++ bindings generation, you have to manually call
`Transaction_free()` even in C++.

Merge pull request #681 from valentinewallace/data-persister-refactor

Add ChannelDataPersister trait and point ChainMonitor to it.

Fix clippy

Rename ChannelMonitor::write_for_disk --> serialize_for_disk

This function does not necessarily write to disk, it can serialize to anything
that implements Writer.

Test that Persist temp and perm failures behave as expected.

If a persister returns a temporary failure, the channel monitor should be able
to be put on ice and then revived later. If a persister returns a permanent
failure, the channel should be force closed.

Add a sample module FilesystemPersister.

Intended to be a cross-platform implementation of the
channelmonitor::Persist trait.

This adds a new lightning-persister crate, that uses the
newly exposed lightning crate's test utilities.

Notably, this crate is pretty small right now. However, due to
future plans to add more data persistence (e.g. persisting the
ChannelManager, etc) and a desire to avoid pulling in filesystem
usage into the core lightning package, it is best for it to be
separated out.

Note: Windows necessitates the use of OpenOptions with the `write`
permission enabled to `sync_all` on a newly opened channel's
data file.

Integrate Persist into ChainMonitor.

- The ChainMonitor should:
  Whenever a new channel is added or updated, these updates
  should be conveyed to the persister and persisted to disk.
  Even if the update errors while it's being applied, the
  updated monitor still needs to be persisted.

Add Persist trait.

Implementors of Persist are responsible for persisting new ChannelMonitors
and ChannelMonitor updates to disk/backups.

Put test utilities behind a feature flag.

The utilities will still be part of cfg(test). The purpose of this
is to enable other crates in the workspace to use the test utilities.

Merge pull request #653 from ariard/2020-06-fix-outputs-tracking

Add outpoint index in watch_outputs to fix tracking

Assert on correct registeration of outputs index

We remove test_no_failure_dust_htlc_local_commitment from our test
framework as this test deliberately throwing junk transaction in
our monitoring parsing code is hitting new assertions.

This test was added in #333, but it sounds as an oversight as the
correctness intention of this test (i.e verifying lack of dust
HTLCs canceling back in case of junk commitment transaction) doesn't
currently break.

[bindings] Add support for `Option<T>` where T is a mapped trait

When mapping an `Option<T>` where T is a mapped trait, we need to
move out of the `*mut T`, however the current generation results in
a `*const T` and a conversion that just takes a reference to the
pointed-to object. This is because the only place this code was
previously used was for slices, which *do* need a reference.

Additionally, we need to know how to convert `Option` containers
which do not contain an opaque type.

Sadly, the easiest way to get the desired result is to add another
special case in container mapping, keeping the current behavior for
slices, but moving out of the pointed-to object for other types.

Ignore cbindgen version in latest-bindings-in-git check.

Currently the check_binidngs GitHub CI job always fails when there
is a new cbindgen release because the cbindgen version is in the
generated header file. When the new version doesn't change the
generated header except for the version number, we should ignore
the difference.

[bindings] Use == null() instead of is_null() to avoid ambiguity

When we have a `Trait` wrapped as an `Option<Trait>`, we called
`<*const Trait>.is_null()` which resulted in rustc trying to take
the most braindead option of dereferencing the whole thing and
hitting a recursive dereference since we
`impl Deref<Target=Trait> for Trait` for all our traits.

Instead, we can be explicit and just compare the pointer directly
with `std::ptr::null()` which avoids this.

[bindings] Include a GenericTypes context in more places

A few places got a None in the previous commit to avoid increasing
the diff size. However, it makes sense to have GenericTypes contexts
there, so we pipe them through the neccessary places.

[bindings] Push generic resolution into resolve_path

Like the previous commit pushing into maybe_resolve_path, this
makes generic resolution a part of type resolution everywhere.

[bindings] Push generic resolution into maybe_resolve_path

This pushes down the logic to check if a given Path is, in fact,
a reference to a generic into the common maybe_resolve_path instead
of doing it redundantly in a few different places. Net loss of LoC.

Support `use ident;` in bindings

Somehow we'd never had any cases of it and it requires an extra
(trivial) match arm.

Add README note about key validity assertions at the FFI boundary

Add test_htlc_no_detection

This test is a mutation to underscore the detetection logic bug
we had before #653. HTLC value routed is above the remaining
balance, thus inverting HTLC and `to_remote` output. HTLC
will come second and it wouldn't be seen by pre-#653 detection
as we were eneumerate()'ing on a watched outputs vector (Vec<TxOut>)
thus implictly relying on outputs order detection for correct
spending children filtering.

Add transaction index in watched_outputs

Previously, outputs were monitored based on txid and an index yelled
from an enumeration over the returned selected outputs by monitoring
code. This is always have been broken but was only discovered while
introducing anchor outputs as those ones rank always first per BIP69.
We didn't have test cases where a HTLC was bigger than a party balance
on a holder commitment and thus not ranking first.

Next commit introduce test coverage.

Merge pull request #738 from TheBlueMatt/2020-10-opt-test

Fix passing -O1 to build from `cargo test`

Merge pull request #740 from rloomba/rloomba/trivial-clippy-fixes

trivial clippy warning fixes

trivial changes to fix clippy::write_with_newline warnings

Merge pull request #739 from rloomba/rloomba/add-clippy-to-travis

Add clippy to Travis integration

add linting to Github CI

add clippy to travis integration

fix all clippy::redundant_field_names warnings

Fix passing -O1 to build from `cargo test`

In 9e03087d6acbc876a5ad1c9b9d8746bf18d5ca86 we started setting
`opt-level` only on profile.test and not profile.dev. When that
commit was authored I tested only that rustc was being called with
opt-level set in its flags, not that the resulted run ran at the
speed I expected. It seems profile.test isn't applied properly to
dependencies or so, resulting in tests running much slower than
they do at profile.dev.opt-level=1.

Merge pull request #734 from TheBlueMatt/2020-10-ci-no-git-conf

Don't let CI fail to check commits b/c git isn't configured in CI

Merge pull request #722 from TheBlueMatt/2020-09-broken-fn

Drop the redundant/broken `ChannelMonitor::get_monitored_outpoints`

Drop now-unused Vec of outpoints in remote-commitment-tx-tracking

This nearly fully reverts 6f08779b0439e7e4367a75f4ee88de093dfb68cb,
removing the extra data storage that it added.

Drop the redundant/broken `ChannelMonitor::get_monitored_outpoints`

In review of the final doc changes in #649, I noticed there
appeared to be redundant monitored-outpoints function in
`ChannelMonitor` - `get_monitored_outpoints()` and
`get_outputs_to_watch()`.

In 6f08779b0439e7e4367a75f4ee88de093dfb68cb,
get_monitored_outpoints() was added, with its behavior largely the
same as today's - only returning the set of remote commitment txn
outputs that we've learned about on-chain. This is clearly not
sufficient, and in 73dce207dd0ea6c3ac57af3ebb8b87ee03e82c9e,
`get_outputs_to_watch` was added which was overly cautious to
ensure nothing was missed. Still, the author of 73dce207dd0ea6c3ac5
(me) seemed entirely unaware of the work in 6f08779b0439e7e4367a75f
(also me), despite the function being the literal next function in
the same file. This is presumably because it was assumed that
`get_monitored_outpoints` referred to oupoints for which we should
monitor for spends of (which is true), while `get_outputs_to_watch`
referred to outpouts which we should monitor for the transaction
containing said output (which is not true), or something of that
nature. Specifically, it is the expected behavior that the only
time we care about `Filter::register_tx` is for the funding
transaction (which we aren't aware of the inputs of), but for all
other transactions we register interest on the basis of an outpoint
in the previous transaction (ie via `Filter::register_output`).

Here we drop the broken-on-day-one `get_monitored_outpoints()`
version, but assert in testing that the values which it would return
are all present in `get_outputs_to_watch()`.

Merge pull request #716 from TheBlueMatt/2020-09-fee-tests

(Fix and) Test that txn pay at least a minimum relay fee in functional tests

Test that txn pay at least a minimum relay fee in functional tests

This also pays a fee on the transactions we generate in response to
SpendableOutputDescriptors in tests.

This fixes the known issues in #630, though we should test for
standardness in other ways as well.

Fix feerate calculation on closing transactions

This resolves a number of bugs around how we calculate feerates on
closing transactions:

 * We previously calculated the weight wrong both by always
   counting two outputs instead of counting the number of outputs
   that actually exist in the closing transaction and by not
   counting the witness redeemscript.
 * We use assertions to check the calculated weight matches what we
   actually build (with debug_assertions for variable-length sigs).
 * As an additional sanity check, we really should check that the
   transaction had at least min-relay-fee when we were the channel
   initator.

Fix max fee_satoshis constant to be 21 million, not 2.1 million.

Though hopefully we never see a fee of 2.1 million BTC, either...

Don't let CI fail to check commits b/c git isn't configured in CI

This fixes #733 by just setting a dummy git name/email before
calling `git rebase` in CI.

Merge pull request #731 from TheBlueMatt/2020-10-fix-big-lock

Actually hold the total_consistency_lock instead of take-and-drop

Merge pull request #730 from TheBlueMatt/2020-09-no-rescan

Drop last bits of rescan as its too complicated to be worth having

Actually hold the total_consistency_lock instead of take-and-drop

It was noticed (via clippy) by @casey that we were taking and then
immediately dropping the total_consistency_lock because `let _ =`
doesn't actually bind the response to anything. This appears to be
a consequence of wanting `if let Some(_) =` to not hold a ref to
the contained value at all, but is relatively surprising to me.

Drop last bits of rescan as its too complicated to be worth having

Previously, we had a concept of "rescaning" blocks when we detected
a need to monitor for a new set of outputs in future blocks while
connecting a block. In such cases, we'd need to possibly learn about
these new spends later in the *same block*, requiring clients who
filter blocks to get a newly-filtered copy of the same block. While
redoing the chain access API, it became increasingly clear this was
an overly complicated API feature, and it seems likely most clients
will not use it anyway.

Further, any client who *does* filter blocks can simply update their
filtering algorithm to include any descendants of matched
transactions in the filter results, avoiding the need for rescan
support entirely.

Thus, it was decided that we'd move forward without rescan support
in #649, however to avoid significant further changes in the
already-large 649, we decided to fully remove support in a
follow-up.

Here, we remove the API features that existed for rescan and fix
the few tests to not rely on it.

After this commit, we now only ever have one possible version of
block connection transactions, making it possible to be
significantly more confident in our test coverage actually
capturing all realistic scenarios.

Drop stale comment about a rescan that doesn't happen in tests

Merge pull request #729 from casey/readme

Add content to readme