Log information about channel freeze/restore from monitor updates

log_trace HTLC changes in Channel::get_update_fulfill_htlc

log_trace HTLC transitions in RAA handling (best reviewed with -b)

log_trace information about commitment txn as they're being built

Merge pull request #302 from TheBlueMatt/2019-01-hashes03

Bump bitcoin_hashes to 0.3

Merge pull request #297 from TheBlueMatt/2019-01-back-fail-privacy

Send back the actual received amount, not expected on HTLC fails

Merge pull request #290 from TheBlueMatt/2019-01-monitor-update-handle-fuzz

Handle monitor update failures in two more places + new fuzz test

Bump bitcoin_hashes to 0.3

Merge pull request #295 from TheBlueMatt/2019-01-holding-cell-limits

Fix holding cell freeing in case we fail to add some HTLC

Fix holding cell freeing in case we fail to add some HTLC

Previously, if we went to free the holding cell HTLC updates, and
adding one failed as we hit our outbound HTLC limit (or in-flight
value limit), we would not send a commitment_signed, leaving us in
an invalid state. We first fix that bug, and then refuse to add
things to our holding cell once we reach our limits considering the
holding cell, as we shouldn't have multiple commitment dance rounds
worth of HTLCs in the holding cell anyway.

Send back the actual received amount, not expected on HTLC fails

This resolves an incorrect implementation of the spec and fixes a
major privacy leak.

Fixes GH #289.

Add a fuzz target to test monitor update failure handling

Sadly this requires reducing the honggfuzz iterations to fit within
Travis' runtime limits.

Take the logger from test_utils into fuzz::test_utils

Expose CommitmentUpdate contents

This is an oversight as the MessageSendEvent is otherwise entirely
useless.

Drop pending outbound messages on peer disconnection

This shouldn't be required, but it may help prevent some downstream
race conditions due to clients not sending message events quickly
enough and trying to send stale messages before new
channel_reestablish messages.

Handle monitor update failures in two more places

Best reviewed with -b

Merge pull request #288 from TheBlueMatt/2019-01-test-split-raa-flag-fix

Fix several more monitor-update-failed cases

Merge pull request #301 from rex4539/fix-typos

Fix typos

Fix typos

Fix responding to RAAs when monitor updating had already failed

Remove incorrect debug_assert!() from reestablish handling and test

Add a test for the ordering setting in channel_reestablish handling

Fix AwaitingRAA on RAA receipt when monitor updating had failed

This fixes a rather subtle case handling RAAs when we don't
generate a response due to a previous monitor update failure, but
would otherwise send a CS response. We need to still set
AwaitingRemoteRevoke on the channl in question, but previously did
not. Found by chanmon_fail_consistency fuzz test with the failing
test converted and added manually.

Merge pull request #300 from TheBlueMatt/2019-01-tests-split

Split up functional_tests into three separate files

Fix indentation in a few new tests

Fix spelling in do_test_monitor_temporary_update_fail comment

Split up monitor-update-failed tests and other functional tests

Split up functional_tests into utils and the tests themselves

Merge pull request #299 from TheBlueMatt/2019-01-262-redux

Added tests to check the bolt 2 specs for open_channel (Sending Node)

Added tests to check the bolt 2 specs for Sending Node Channel

Merge pull request #298 from TheBlueMatt/2019-01-271-cleanup

Implement serialize/deserialize for Router

Implement serialize/deserialize for Router.

Extend route_test to check if serialize/deserialize of
NetworkMap works.

Add PartialEq traits on some Router's structs.

Modify also UnsignedNodeAnnouncement serialization

Implement Writeable/Readable for Option<T>

Add OptionalField in OpenChannel, AcceptChannel
ChannelReestablish to avoid serialization implementation
conflicts

Merge pull request #286 from TheBlueMatt/2019-01-monitor-update-fixes

Fix a few monitor-update failure bugs found by new fuzzer

Fix handling RAA when a monitor update previously failed

Rewrite monitor_update_failed as it didn't capture all the options

Primarily this fixes the case where we receive an RAA which does
not require a response, allowing us to call monitor_update_failed
without generating pending messages.

Remove unused argument from handle_error!

Merge pull request #294 from TheBlueMatt/2019-01-deps-bump

Upgrade to secp256k1 v12, bitcoin v16, and crates bitcoin_hashes

Ensure Message always unwraps in fuzztarget

Hashes cant be all-0s, so we can normally unwrap, but fuzztarget
can generate all-0 hashes, so we have to handle it and swap for
something else.

Drop verification context from keys manager

Upgrade to secp256k1 v12, bitcoin v16, and crates bitcoin_hashes

Merge pull request #203 from TheBlueMatt/2018-10-router-htlc-min

Fix Router min HTLC comparison

Merge pull request #296 from TheBlueMatt/2019-01-291-rebased

Wrote test to explicitly test BOLT 2 requirements for update_add_htlc

Fix Router min HTLC comparison

Wrote test to explicitly test BOLT 2 requirements for update_add_htlc

(minor tweaks by @TheBlueMatt)

Merge pull request #285 from TheBlueMatt/2019-01-fuzz-cleanups

Trivial cleanups in full_stack_target/fuzztarget

Merge pull request #284 from TheBlueMatt/2019-01-remote-htlc-timeout-broadcast

Check for timing-out HTLCs in remote unrevoked commitments

Fix comment spelling and clarify algebra a bit.

Check for timing-out HTLCs in remote unrevoked commitments

This resolves a TODO/issue in would_broadcast_at_height where we
will not fail a channel with HTLCs which time out in remote
broadcastable transactions.

Test for failing channel after local commitment dust HTLC timeout

Merge tracking of HTLCs-in-commitment with outbound-HTLCs

This simplifies a few things, deduplicates a some small memory
overhead, and, most importantly, is a first step to fixing
would_broadcast_at_height.

Make HTLCOutputInCommitment::transaction_output_index an Option

We really shouldn't have split out the with-source HTLCs from the
in-transaction HTLCs when we added back-failing, and will need
almost all of the info in HTLCOutputInCommitment for each HTLC to
fix would_broadcast_at_height, so this is a first step at
recombining them.

Merge pull request #283 from TheBlueMatt/2019-01-htlc-resolution-log

Simplify and expand logging in is_resolving_htlc_output

Merge pull request #282 from TheBlueMatt/2019-01-multi-htlc-claims

Fix multi-remote-HTLC-claim preimage learning

Simplify and expand logging in is_resolving_htlc_output

This clarifies all the conditions we can hit and also ensures they
are all logged in a clear and consistent manner.

Fix multi-remote-HTLC-claim preimage learning

When our counterparty claims multiple HTLCs from offered outputs in
one transaction we should still be able to learn the preimages.
Sadly, due to two bugs we were not previously doing so.

Fix source name in is_resolving_htlc_output

Fix dead_code warnings in fuzztarget builds

Switch to bitcoin_hashes Hash160 in full_stack_target

Add doc to full_stack_target

Add option to use libfuzzer sys in full_stack_target

Note that there doesn't appear to be a way to conditionally set
 #[no_main] so that has to happen manually at compile-time.

Merge pull request #280 from TheBlueMatt/2018-12-no-to-remote-revoked-htlcs

Move fail-backwards up for no to-remote output claims

Fix stale comment in functional_tests after failing back async

Macro-DRY HTLC back-fails for revoked remote transaction broadcast

Add test_commitment_revoked_fail_backward_exhaustive no_to_remote

This tests a case we previously didn't handle correctly where we
returned early if there was no to_remote output to claim and thus
failed to fail-backwards HTLCs which were present.

Add dust mode to test_commitment_revoked_fail_backward_exhaustive

This tests that we fail back HTLCs that don't make it into
commitment transactions the same as we test ones that do.

Merge pull request #281 from ariard/harden-inbound-htlc-resolved

Harden test for logging of inbound htlc being resolved

Log resolution of offered HTLC by HTLC-timeout tx

Move fail-backwards up for no to-remote output claims

This fixes HTLC fail-backwards in case we haven't yet sent enough
to have a to_remote output to claim, plus some edge cases where it
could be removed due to a fee update, though hopefully that goes
away with simplified_commitment.

Merge pull request #278 from TheBlueMatt/2018-12-fail-on-unrevoked-remote

Fail HTLC backwards on unrevoked remote commitment tx broadcast

More comments/hardening test_fail_backwards_unrevoked_remote_announce

Fail HTLC backwards on unrevoked remote commitment tx broadcast

Macro-out BroadcastChannelUpdate-on-channel-close in func tests

Log errors forwarding/failing HTLCs

Remove long-stale TODO

Merge pull request #276 from TheBlueMatt/2018-12-async-fail

 Fail HTLCs backwards asynchronously

Fail HTLCs backwards asynchronously

Add an enum option to pending forwards to fail backwards

Refactor HTLCForwardInfo into an enum in prep for delayed-fail

macro-out a bunch of PendingHTLCsForwardable+forward calls

Move process_onion_failure into onion_utils

Merge pull request #275 from TheBlueMatt/2018-12-manager-split

Split up ChannelManager

Drop needless mut found by rustc 1.22

Move ChannelManager network tests into their own module

Move onion encryption/decryption/etc into an onion_utils module

Drop channel_held_info which was only for the channel fuzz target

Merge pull request #270 from TheBlueMatt/2018-12-drop-rust-crypto

Drop rust-crypto for bitcoin_hashes

trace_log more in channelmonitor

Use bitcoin_hashes' fixed_time_eq, removing the rust-crypto dep

Drop rust-crypto trait usage

Steal rust-crypto's Poly1305 implementation wholesale

Steal rust-crypto's ChaCha20 implementation wholesale

Use bitcoin_hashes' Ripemd160/Hash160 from rust-crypto+rust-bitcoin

Note that this requires rewriting full_stack_target tests, which
sucks, but it does let the fuzzer hit more stuff since the real
ripemd160 isn't ever actually called anymore.

Switch Sha256 to using bitcoin_hashes and our own HKDF

Change the way channel keys are generated

This fixes a somewhat-misuse of HKDF in ChannelKeys::new_from_seed,
but much more importantly removes a use of rust-crypto's HKDF funcs

Merge pull request #274 from TheBlueMatt/2018-12-243-review

Onion Error Handling

Update incorrect_payment_amount generation/handling for BOLT uptd

ie dont generate them as they're a really obvious privacy leak.
Luckily we were already handling them the same aside from log
printing so don't have to touch anything there. I was lazy in
updating tests but it only effects log printing, so whatever.

Add tests for process_onion_failure return value sanity

Add test_util for overriding session privs for onion crypt

Add some additional channel-creation-broadcast-msg sanity checks