Further clean up some comments wrt the peer socket handling API

Merge pull request #512 from TheBlueMatt/2020-02-peer_handler-docs

Fix incorrect docs/disconnect handling in peer_handler

Merge pull request #474 from TheBlueMatt/2020-02-htlc-updated-in-monitors

Move pending-HTLC-updated ChannelMonitor from ManyChannelMonitor

Fix incorrect docs around disconnect in peer_handler + rename fns

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat and rename a few functions to clarify
what they actually do.

Test basic HTLC claim behavior from monitor -> manager on reorg

Move pending-HTLC-updated ChannelMonitor from ManyChannelMonitor

This is important for a number of reasons:
 * Firstly, I hit this trying to implement rescan in the demo
   bitcoinrpc client - if individual ChannelMonitors are out of
   sync with each other, we cannot add them all into a
   ManyChannelMonitor together and then rescan, but need to rescan
   them individually without having to do a bunch of manual work.
   Of the three return values in ChannelMonitor::block_connected,
   only the HTLCsource stuff that is moved here makes no sense to
   be exposed to the user.
 * Secondly, the logic currently in ManyChannelMonitor cannot be
   reproduced by the user! HTLCSource is deliberately an opaque
   type but we use its data to decide which things to keep when
   inserting into the HashMap. This would prevent a user from
   properly implementing a replacement ManyChannelMonitor, which is
   unacceptable.
 * Finally, by moving the tracking into ChannelMonitor, we can
   serialize them out, which prevents us from forgetting them when
   loading from disk, though there are still other races which need
   to be handled to make this fully safe (see TODOs in
   ChannelManager).

This is safe as no two entries can have the same HTLCSource across
different channels (or, if they did, it would be a rather serious
bug), though note that, IIRC, when this code was added, the
HTLCSource field in the values was not present.

We also take this opportunity to rename the fetch function to match
our other event interfaces, makaing it clear that by calling the
function the set of HTLCUpdates will also be cleared.

Merge pull request #514 from TheBlueMatt/2020-02-no-lto-travis-fuzz

Skip lto on travis when building fuzz targets as it takes 30 min

Skip lto on travis when building fuzz targets as it takes 30 min

Merge pull request #510 from TheBlueMatt/2020-02-fewer-fuzz-rustc-warns

Silence new rustc warnings re: extra ()s, dyn, and unused params

Merge pull request #511 from TheBlueMatt/2020-02-test-pub-in-test-only

Only expose constants exposed for testing in cfg(test)

Only expose constants exposed for testing in cfg(test)

Silence new rustc warnings re: extra ()s, dyn, and unused params

Merge pull request #506 from arik-so/ping_encryption_fix

Encrypt ping messages before sending them

Remove unused code in peer handler test utility method.

Merge pull request #508 from maxgiraldo/2020-02-sp-grammar

docs(CONTRIBUTING): fix spelling and grammar

Fix ping message sent on timer ticks to be encrypted so the peer can decrypt it instead of shutting down the connection.

docs(CONTRIBUTING): fix spelling and grammar

Fix some minor spelling and grammar mistakes.

Merge pull request #502 from rloomba/rloomba/add_unregister_listener

[chaininterface] Add ability for BlockNotifier to unregister listeners

Merge pull request #503 from TheBlueMatt/2020-02-chanmon-ser-roundtrip

Fix Two Bugs around ChannelManager serialization round-trip

Merge pull request #455 from TheBlueMatt/2020-01-monitor-reload-watch

Track the full list of outpoints a chanmon wants monitoring for

Allow deserialization of new Channels before we've seen a block

Previously, if we have a live ChannelManager (that has seen blocks)
and we open a new Channel, if we serialize that ChannelManager
before a new block comes in, we'll fail to deserialize it. This is
the result of an overly-ambigious last_block_connected check which
would see 0s for the new channel but the previous block for the
ChannelManager as a whole.

We add a new test which catches this error as well as hopefully
getting some test coverage for other similar issues in the future.

Fix serialization rt bug in Channel and test in functional_tests

Previously, when attempting to write out a channel with some
RemoteAnnounced pending inbound HTLCs, we'd write out the count
without them, but write out some of their fields. We should drop
them as intended as they will need to be reannounced upon
reconnection.

This was found while attempting to simply reproduce a different
bug by adding tests for ChannelManager serialization rount-trip at
the end of each functional_test (in Node::drop). That test is
included here to prevent some classes of similar bugs in the future.

Add comment describing how ChannelMonitor::block_connected is called

Test that we don't forget to track any outputs at monitor-load

This tests, after each functional test, that if we serialize and
reload all of our ChannelMonitors we end up tracking the same set
of outputs as before.

Track the full list of outpoints a chanmon wants monitoring for.

Upon deserialization/reload we need to be able to register each
outpoint which spends the commitment txo which a channelmonitor
believes to be on chain. While our other internal tracking is
likely sufficient to regenerate these, its much easier to simply
track all outpouts we've ever generated, so we do that here.

add functionality for BlockNotifier to unregister a previously registered listener, in order to no longer receive events

Merge pull request #440 from TheBlueMatt/2020-01-feature-sanity

Fix a bug in required feature checks

Merge pull request #499 from moneyball/patch-1

add clarity to the language

fixes per rloomba feedback

Merge pull request #501 from TheBlueMatt/2020-02-rescan-clarify

Clarify rescan rules for block_connected somewhat

fixes per arik feedback

Clarify rescan rules for block_connected somewhat

add clarity to the language

Add some basic sanity tests for feature flags

Avoid treating option_upfront_shutdown (req) as unknown_required.

This fixes the bitmask in requires_unknown_bits.

Merge pull request #470 from ariard/2020-01-contributing-draft

First draft, don't-cover-everything-but-yet-a-good-start-CONTRIBUTING.md

Merge pull request #496 from TheBlueMatt/2020-02-461-extra-mut

Remove unnecessary mut introduced in 0c595a7ff69bd177b2e7fa8c1b361

Add a first draft CONTRIBUTING.md

Remove unnecessary mut introduced in 0c595a7ff69bd177b2e7fa8c1b361

Merge pull request #461 from ariard/2020-remove-duplicata

Remove some duplicata of broadcast txn from ChannelMonitor

Remove duplicata of broadcast txn from ChannelMonitor

Previously, if new ouputs were found to be watched as part
of channel operations, the block was rescan which triggers
again parser and generation of transactions already issued.

This commit first modifies the test framework without
altering further ChannelMonitor.

ChannelMonitor refactoring is introduced in a latter commit.

Merge pull request #434 from TheBlueMatt/2019-12-var-len-onion

TLV-based Variable Length Onion

Define a BLOCK_SIZE constant for chacha20

Swap out 20*65 for a constant, given onion hops are now of var len

Use RouteHop's new node_features to send TLV-encoded onion hops

This implements the new TLV variable-length encoding for onion hop
data, opting to send it if the RouteHop's node_features indicates
support. It also uses the new process_inline method in ChaCha20 to
optimize a few things (though it grows a new TODO for a
probably-important optimization).

Add support for variable-length onion payload reads using TLV

Add macros for building TLV (de)serializers.

There's quite a bit of machinery included here, but it neatly
avoids any dynamic allocation during TLV deserialization, and the
calling side looks nice and simple. The macro-generated code is
pretty nice, though has some redundant if statements (I haven't
checked if they get optimized out yet, but I can't imagine they
don't).

Expose VecWriter outside of util::ser since peer_handler uses it

Add new streams and serialization wrappers for TLV types.

This adds a number of new stream adapters to track and/or calculate
the number of bytes read/written to an underlying stream, as well
as wrappers for the two (?!) variable-length integer types that TLV
introduces.

Add a ChaChaReader adapter to read an encrypted stream & use it

This prepares for variable-length per-hop-data by wrapping the full
hop_data field in a decrypting stream, with a few minor
optimizations and redundant allocations to boot.

Move BogusHopData generation into test instead of OnionHopData.

This, as it should be, restricts OnionHopData to only being able to
represent valid states, while still allowing for tests to generate
bogus hop data fields to test deserialization.

Pull hmac out of OnionHopData.

Its a bit awkward to have an hmac field covering the struct that
its in, and there is little difference in removing it, so just pull
it out and use a [u8; 32] where we care about the hmac.

Flatten OnionHopData struct with the Realm0 struct.

Previously OnionHopData contained a OnionRealm0HopData field however
instead of bumping the realm number, it has been replaced with a
length, used to indicte the length of a TLV-formatted object.

Because a TLV-formatted hop data can contain the same information as
a realm-0 hop data, we flatten the field and simply keep track of
what format it was in.

Better document msg fuzz target behavior and be slightly more strict

Merge pull request #491 from TheBlueMatt/2020-02-one-conf-lock

Fix one-confirmation funding_locked generation

Merge pull request #490 from jkczyz/2020-02-initial-routing-sync

Refactor logic for setting initial_routing_sync feature bit

Add some trace logging for funding_locked and announcement_sigs

Add test for 1-conf channels

Fix sending funding_locked with 1 conf.

We previously tracked funding transaction confirmation by marking
funding_tx_confirmations to 1 when we see it in a block and
incrementing each block thereafter if its non-0. To avoid
double-incrementing the first confirmation, we did the increment
(and funding_locked check) after doing the first-confirmation
checks. Thus, we'd never hit the funding_locked case during the
first confirmation.

To address this, we simply swap the order of the checks, though
bumping the funding_tx_confirmations increment up to the top.

Reported-by: Igor Cota <igor@codexapertus.com>

Add a test for Router's should_request_full_sync

Move Router test setup to a helper function

Move initial_routing_sync decision to the Router

PeerManager determines whether the initial_routing_sync feature bit
should be set when sending Init messages to peers. Move this to the
Router as it is better able to determine if a full sync is needed.

Merge pull request #445 from TheBlueMatt/2020-01-fuzz-enforcer-fix

Fix EnforcingChannelKeys panic when our counterparty burns their $.

Merge pull request #487 from moneyball/master

remove unnecessary reference to LDK

Update README.md

Merge pull request #479 from moneyball/master

Updated the status of the project

Merge pull request #478 from arik-so/remove_decodeerror_macro

remove decode_error macro only used once

Test that EnforcingChannelKeys doesn't panic on duplicate RAAs

Fix EnforcingChannelKeys panic when our counterparty burns their $.

If our counterparty burns their funds by revoking their current
commitment transaction before we've sent them a new one, we'll step
forward the remote commitment number. This would be otherwise fine
(and may even encourage them to broadcast their revoked state(s) on
chain), except that our new EnforcingChannelKeys expects us to not
jump forward in time. Since it isn't too important that we punish
our counterparty in such a corner-case, we opt to just close the
channel in such a case and move on.

Update README.md

Updated the status of the project

It needs review and completion of the missing BOLT specification parts.

remove decode_error macro only used once

Merge pull request #463 from jkczyz/2020-01-wire-encode

Encapsulate message wire encoding into a module

Use a tuple struct for MessageType

Move message type parity logic to the wire module

Create a MessageType abstraction and use it throughout the wire module's
external interfaces. Include an is_even method for clients to determine
how to handle unknown messages.

Encapsulate message wire encoding into a module

Lightning messages are identified by a 2-byte type when encoded on the
wire. Rather than expecting callers to know message types when sending
messages to peers, have each message implement a trait defining the
message type. Provide an interface for reading and writing messages
as well as a Message enum for matching the decoded message, including
unknown messages.

Merge pull request #454 from TheBlueMatt/2020-01-fuzz-mega-value

Panic on txn with value > 21mill in ChannelMonitor::block_connected, Clean up fuzz targets a bit

Merge pull request #466 from lightning-signer/chanmon-keys

Add ChannelKeys to ChannelMonitor

Add ChannelKeys to ChannelMonitor

move ChannelMonitor.write* in preparation for adding ChannelKeys

Explicit pass index at HTLC spending transaction signing

Merge pull request #459 from ariard/2020-01-fix-htlc-height-timer

Fix bumping timer for claiming revoked HTLC outputs

Merge pull request #460 from lightning-signer/channel-value

Channel value to ChannelKeys constructor

Merge pull request #458 from TheBlueMatt/2020-01-spendable-docs

Clean up documentation around spendable outputs significantly.

Merge pull request #443 from valentinewallace/channelmgr-arcs-to-derefs

Drop ChannelManager's ChannelMonitor Arc for Deref

Clean up documentation around spendable outputs significantly.

 * Fixed a number of grammar issues
 * Clarified the docs for users who are intimately farmiliar with
   arbitrary lines of text copied from the BOLTs
 * Added a bit more text so that things are easier to read and less
   disjoint.
 * Clarified exactly how the witness stack should look since I had
   to go dig for it.

Update ChannelManager's ChannelMonitor Arc to be a Deref

Additional changes:
* Update fuzz crate to match ChannelManager's new API
* Update lightning-net-tokio library to match ChannelManager's new ChannelMonitor Deref API
* Update tests to match ChannelManager's new ChannelMonitor Deref API

Remove unnecessary sign_closing_transaction arg

channel value to ChannelKeys constructor

Fix bumping timer for claiming revoked HTLC outputs

Previously, we were using their_to_self_delay instead of
our_to_self_delay which was falsifying test.

Merge pull request #457 from ariard/2020-01-fix-append-onchain

Fix spurious calls of broadcast_by_local_state

Merge pull request #433 from TheBlueMatt/2019-12-features-in-routes

Plumb Features through into Routes

Fix spurious calls of broadcast_by_local_state

DRY-up list_channels by having a common lister that takes a filter

Pass node features through to RouteHops

This exposes the latest Init-context features in the ChannelDetails
passed to the Router during route calculation, which combines those
with the Node-context features tracked from node_announcements to
provide the latest Node-context features in RouteHop structs.

Fields are also added for Channel-context features, though those are
only partially used since no such features are defined today anyway.

These will be useful when determining whether to use new
TLV-formatted onion hop datas when generating onions for peers.

Keep track of the Init Features for every connected/channel'd peer

Since we want to keep track of the Init-context features for every
peer we have channels with, we have to keep them for as long as the
peer is connected (since we may open a channel with them at any
point).

We go ahead and take this opportunity to create a new per-peer-state
struct which has two levels of mutexes which is appropriate for
moving channel storage to.

Since we can't process messages from a given peer in parallel, the
inner lock is a regular mutex, but the outer lock is RW so that we
can process for different peers at the same time with an outer read
lock.

Pass peer's Init message through to ChannelManager

Merge pull request #451 from lightning-signer/txkeys

Provide remote channel public keys to signer

Use ChannelPublicKeys in Channel

Hide derived fields in TxCreationKeys