Delay closing_signed until update_fee exchanges complete

See https://github.com/lightningnetwork/lightning-rfc/issues/499
for a bit more about the ambiguity we're addressing here.

Also drop holding cell update_fee the same way we drop holding
cell update_add_htlcs when sending shutdown, resolving a bug.

Fail incoming HTLCs sent after we start shutdown, not the chan

Send closing_signed when appropriate as pending HTLCs clear

Always send Shutdown resposnes to Shutdown messages

We always require that any changes to Channel state be committed
immediately (within the same lock) so we should never have
uncommitted changes which would prevent us from sending a Shutdown
response.

Refactor out first-closing-sent creation

Use ChannelError in shutdown handling, clean up, impl err actions

Add warnings reminding users to use SegWit funding inputs

Merge pull request #235 from TheBlueMatt/2018-10-229-redux

Bug fix using same seed sequence for channel key geneartion

Bug fix using same seed sequence for channel key geneartion

Merge pull request #234 from TheBlueMatt/2018-10-169-redux

169 Tweaked

Added config interface to allow users to specify channel limits

Require at least 1k sat for outbound channels and meet BTC's dust

Use non-funder's funding block wait instead of max with ours

This is both required by the protocol and also makes sense - if
we're the funder we don't mind accepting payment on the channel
after one confirmation because we assume we won't double-spend
ourselves.

Merge pull request #232 from TheBlueMatt/master

Fix a full_stack_target crash

[full_stack_target] don't allow double-confirming txn

Give ManyChannelMonitor a logger and trace add_update events

Merge pull request #226 from TheBlueMatt/2018-10-0.0.6

Bump version to 0.0.6

Merge pull request #223 from TheBlueMatt/2018-10-chanmanager-serialize

Implement and document Channel/ChannelManager (de)serialization

Merge pull request #222 from TheBlueMatt/2018-10-pre-commit-disconnect

Fix and test update_add_htlc but disconnect pre-commitment_signed

Merge pull request #217 from TheBlueMatt/2018-10-msg-resp-overhaul

Send ChannelManager messages out-of-band to ensure ordered delivery

Merge pull request #225 from TheBlueMatt/2018-10-214-redo

Keys Interface Simplification

Bump version to 0.0.6

Add very basic test of ChannelManager serialization round-trip

fix broken state comparison (thanks @yuntai!)

Implement and document Channel/ChannelManager (de)serialization

Fix + test disconnect/reconnect prior to FundingLocked

Fix and test update_add_htlc but disconnect pre-commitment_signed

Avoid reentrancy of send_data from PeerHandler::read_bytes.

This greatly simplifies clients of PeerHandler, and because almost
all response messages have already been moved to process_events
this doesn't change much effeciency-wise.

Integrate destination_script from KeysInterface in ChannelManager/Channel

Drop channel_monitor_claim_key from ChannelKeys

Store+expose bits of Channel[Monitor] to figure out local state

Send channel_reestablish out-of-band to ensure ordered deliver

Integrate shutdown_pubkey from KeysInterface in ChannelManager/Channel

Drop channel_close_key from ChannelKeys

Track ChannelMonitor-watched-outpoints (+ remove now-uesless Mutex)

Respond to channel_reestablish out-of-band for ordered delivery

Integrate KeysInterface to ChannelManager with Arc

Track last_block_hash in ChannelMonitor and expose it on deser

Also make block_connected take a &mut self to ensure serialized
state will always be self-consistent.

Send RAA/CS messages out-of-band to ensure ordered delivery

Implement KeysInterface for KeysManager util

Redo ChannelMonitor deserialization to avoid read_to_end()

This slightly changes the serialization format, but we're still
early enough that that's OK.

Send shutdown/closing_signed msgs out-of-band for ordered delivery

impl some additional (de)serializers, including a u48 wrapper type

Send announcement_signatures msgs out-of-band for ordered delivery

impl Readable/Writable for Route

Send funding_signed messages out-of-band to ensure ordered delivery

Add a BIG lock to ChannelManager

During normal operation we should never need to take this, so we
use a RwLock that allows normal parallelism until we want to
serialize out our ChannelManager, at which point we can take the
write-mode lock.

Send AcceptChannel responses out-of-band to ensure ordered delivery

Give ChannelMonitor a logger via new ReadableArgs trait

Split Event, move MessageSendEvent push() inside channel_state lock

Add a second Readable trait for state args, clean macros slightly

Store [u8; 32]s instead of SharedSecrets (for deserialization)

Add a KeysInterface which provides keys from user

Move ChannelKeys into keysinterface for generate a set of it from
master_seed and change return type to panic on bogus data

Generate Events from ChannelMonitor to indicate spendable ouputs

Extend KeyStorage with delayed_payment_base_key and per_commitment_point
to derive local_delayed private key

Merge pull request #224 from TheBlueMatt/2018-10-221-whitespace

#221 with a few trailing spaces removed

Comments updated for PaymentReceived

Merge pull request #220 from TheBlueMatt/2018-10-oops-xxx

Fix XXXs that slipped into router and handle HTLCFailCHannelUpdates

Run travis-fuzz on Rust 1.29.2 due to 1.30 breaking honggfuzz build

Add PaymentFailReason for fail_htlc_backwards

to indicate fail reason after a PaymentReceived event

Fix XXXs that slipped into router and handle HTLCFailCHannelUpdates

Merge pull request #213 from TheBlueMatt/2018-10-monitor-fail-pause

Add  ChannelManager support for monitor update failure in one place

Add basic sanity testing for channel monitor update failure handle

ChannelManager support for monitor update failure in one place

Add Channel support for monitor-update-failed pausing

Add an Event for sending revoke_and_ack messages out-of-band

Pull out the HTLC forwarding loop into a function

Pull out regenerating RAA/CS in channel_reestablish handling

Move channel monitor updates inside the channel_state lock

This really, really sucks as it defeats almost all of the
cross-channel parallelism we'd intended to have - waiting on a
client to update a watchtower for an unrelated channel to process
any messages is really shitty. We should revisit this with
per-channel locks as a compile-time option post-0.1.

Merge pull request #212 from TheBlueMatt/2018-10-two-updates-disconnect

Fix reconnect message order on remote updates while waiting on RAA

Add test for two-updates-in-flight disconnect channel resumption

Fix reconnect message order on remote updates while waiting on RAA

Add message ordering return value to handling channel_reestablish

Merge pull request #219 from TheBlueMatt/2018-10-157-merge

Partially implement more onion error handling for sent payments

Move HTLCFailChannelUpdate handling out-of-band

While this isn't neccessary for message ordering consistency, this
does mean that we won't end up processing an HTLCFailChannelUpdate
from a update_fail_htlc prior to it being fully committed (where if
the peer disconnects/reconnects it could theoretically give us a
different result, eg if their next-hop reconnected to them).

Partially implement more onion error handling for sent payments

Also refactor out onion error handling into a function instead of
in update_fail_htlc.

Cache the initial htlc_msat that we sent instead of recalculating
it to check validity of the error returned.

Some changes in comments and error messages.

Error handling in decoding onion

Add is_permanent field to ChannelClosed message and add NodeFailure
message

Avoid needless on-chain channel failing for timing-out HTLCs

See new comments in code for more details

Merge pull request #211 from TheBlueMatt/2018-10-misc-cleanups

Miscellaneous Cleanups

Test double-reconnect

Use APIError::ChannelUnavailable a bit more for consistency

Ensure channel is live, not usable for sending fee updates

+ a freebie TODO removal

Use live, not usable for list_usable_channels

Merge pull request #210 from TheBlueMatt/2018-10-funding-disconnected

Fix + test funding tx confirmation while peer is disconnected

Fix + test funding tx confirmation while peer is disconnected

Merge pull request #208 from TheBlueMatt/2018-10-reconnect-fixes

Fix channel_reestablish exchanging in case of lost messages

Add documentation about PaymentSent/Failed event duplication bug

Test reconnecting after lost message(s) during the commitment dance

Fix channel_reestablish exchanging in case of lost messages

This uses the new storage in HTLC state enums to reproduce the
various updates in a CommitmentUpdate group which is obviously
required to re-send a commitment_update after pending unreceived
updates were dropped.

Does not yet handle dropped update_fee updates properly.

Store onion packet in OutboundHTLCState so we can regen update_add

Store per-state HTLC data in the state enum itself (and store more)

Split create_chan_between_nodes into two steps

Merge pull request #206 from TheBlueMatt/2018-10-189-rebase

#189 rebased

Further simplify get_{inbound,outbound}_pending_htlc_stats

Split get_pending_htlc_stats

to get_inbound_pending_htlc_stats and get_outbound_pending_htlc_stats

Check that reserves are met or progress is made on commitment tx gen

Add test for channel_reserve with holding cell HTLCs counted

Add simple test for channel_reserve/max_htlc_value_in_flight_msat

Break up test channel creation to specify values explicitly

Add a ChannelValueStat getter to simplify tests

Document channel reserve behavior a bit better