Address PR comments

Addressed PR comments

Wrote test to explicitly test BOLT 2 requirements for update_add_htlc

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

Always return malformed for BADONION errors

Also be willing to forward something with a pubkey that we know is
complete garbage, but upstream will just fail that with BADONION
when they get it.

I think this is kinda intended by the spec, but it definitely needs
to be clarified.

Add TODO noting confusion over |20 (channel_disabled) definition

Include flags when sending channel_disabled onion errors

Rewrite most of process_onion_failure

Swap an if let for a match and add some TODO

Merge pull request #273 from ariard/2018-12-17-replace-by-permanent-channel-failure

Replace some unknown_next_peer by permanent_channel_failure

Replace some unknown_next_peer by permanent_channel_failure

Merge pull request #269 from TheBlueMatt/2018-12-198-review

Detect HTLC-resolving on-chain actions and pass them to ChannelManager

Add some TODOs for correctness in ChannelMonitor

Add constant for HTLC failure anti-reorg delay

Include the node id in ChannelManager test logs

Add additional log traces in channelmonitor/manager

Add logging of HTLC outputs resolved by remote peer justice tx

In case of broadcast of revoked local commitment tx, we may be
interested that we've screwed up

Typify payment_hash and payment_preimage

Fix variable name as payment_hash instead of txid for index
of remote_hash_commitment_number in ChannelMonitor reader

Add bigger test for failing HTLCs claimed through revocation

Add test for failing/fulfilling HTLCs from on-chain actions

Including detection of timeout claims, fulfill claims, and
failing all current HTLCs in case of revoked-commitment broadcast.

Add const ACCEPTED_HTLC_SCRIPT_WEIGHT and OFFERED_HTLC_SCRIPT_WEIGHT to
ease readability

Conditionnal compilation for weight of second one to handle test special
cltv values

Generate PaymentFailed events for outbound payments we fail

Move monitor-generated HTLC event handling to manager event-getters

This is somewhat awkward, but prevents a slew of duplicate events.
Really this should probably be more explicit, but would be easy to
move that along with a slew of block_connected-event-processing
refactors, see-also GH #80.

This affects full_stack_target only on accident cause the demo test
didn't continue onwards with another block connection.

Fail all pending HTLCs if the remote broadcasts a revoked tx

Detect onchain timeout of a HTLC in ChannelManager block_connected

Pass failure backward

Add is_resolving_output in ChannelMonitor

Called in ChannelMonitor block_connected, returning
HTLCUpdate upstream via ManyChannelMonitor to
link htlcs between monitors. Used by ChannelManager to
fulfill/fail htlcs backwards accordingly

If spurrious HTLCUpdate are generated due to block re-scan
and htlc are already LocalRemoved, discard them in
channel get_update_*_htlc

Return refs from build_commitment_transaction, removing clone()s

Track HTLCSource in ChannelMonitor

Insert it in current_local_signed_tx, prev_local_signed_tx,
remote_claimable_outpoints. For so get it provided by
Channel calls to provide_latest_{local,remote}_tx

Track outputs fron local commitment tx

Aims to detect onchain resolution of channel

Modify in consequence test_txn_broadcast to still pass
channel_monitor_network_test

Modify some tests due to block re-scan caused by
detections extensions

Merge pull request #266 from TheBlueMatt/2018-12-closing_signed-3-leg-commitment

Remove check which makes us sometimes never send closing_signed

Merge pull request #263 from TheBlueMatt/2018-12-monitor-fail-2

Handle monitor update failures in msg-recv functions

Expand comment on ChannelMonitorUpdateErr::PermanentFailure a bit

Add test for monitor update failure on CS/RAA/CR handling

Handle monitor update failures in msg-recv functions

This adds a few TODOs around further message rebroadcasting which
needs to be implemented as well as some loss of tracking of HTLCs
on permanent channel failure which needs to get transferred over to
the appropriate in-memory ChannelMonitor.

Swap handle_monitor_update_fail for a macro ala try_chan_entry

This resolves an API bug where send_payment may return a
MonitorUpdateFailed Err both when the payment will not be sent and
when the HTLC will be retried automatically when monitor updating
is restored. This makes it impossible for a client to know when
they should retry a payment and when they should not.

Merge pull request #268 from TheBlueMatt/2015-12-fuzz-fix-output-idx

Check tx output matches monitor output data (and is sufficient len)

Check tx output matches monitor output data (and is sufficient len)

Fixes a panic found by fuzzer in case the monitor per-commitment
data is garbage. We had a similar check for revoked commitment tx
but didn't copy it down to non-revoked commitment tx, so do that
now.

Merge pull request #264 from TheBlueMatt/2018-12-198-first-commit

Refactor KeyStorage as Storage

Unify the update pattern in provide_latest_local_commitment_tx_info

Simplify ChannelMonitor Storage updates a bit

Simplify insert_combine by unimplemented!()ing unimplemented things

Refactor KeyStorage as Storage

Move PrivMode as Local, SigsMode as Watchtower

Cut funnding_txo from ChannelMonitor, move it inside Local

Rename log_funding_option as log_funding_info

Remove check which makes us sometimes never send closing_signed

This is the case pointed out by nayuta-gondo at
https://github.com/lightningnetwork/lightning-rfc/issues/499#issuecomment-438623208
though this doesn't actually solve the issue of ensuring we have a
consistent fee view when we start shutdown processing. There isn't
a clear solution to that however without adding additional state
tracking in Channel.

This also removes an associated test that tests for the correct
behavior (but didn't consider the bug) as we no longer behave
correctly. This should be fine as we'll be removing all the
update_fee garbage with option_simplified_commitment anyway.

Merge pull request #265 from TheBlueMatt/2018-12-fuzz-fix-no-witness

Fix crash on no-witness tx in ChannelMonitor found by fuzzer

Avoid writing to stdout during fuzz tests

Remove unused import in full_stack_target