Fundchannel: extend fundchannel_cancel to work before funding broadcast

[trueptolemy]

Fix #2740
This PR try to make fundchannel_cancel can work after fundchannel_complete and before funding broadcast.

Process

The extended process is:
For funder:

• At the first, funder used funderchannel_complete;
• Then funder calls funderchannel_cancel:
  • funder check if the fundchannel process completed ==>
  • If completed, funder check if its clightning has broadcast the funding and check if the funding has been onchain ==>
  • If these 2 check pass, funder ask its channeld send a error message to fundee ==>
  • After sending error message, the funder delete(forget) the channel(also delete the peer, it's the limit of delete_channel())

For fundee:

• After funder's funderchannel_complete, the channel state is AWAITING_LOCKIN. And the fundee begin to wait for funding locked both locally and remotely
• During AWAITING_LOCKIN, when fundee receives the error message from funder, fundee will delete(forget) the channel(also delete the peer, because of the limit of notify_disconnect when remote peer sends error? #2741 )

Limits

But here's also some limits:

• The check for funding broadcast can't completely ensure that the funding transaction isn't broadcast. We can't know the case if the funding is broadcast by external wallet but the transaction hasn't been onchain.
  This also ask caller to use fundchannel_cancel correctly: must be before funding broadcast.
• If fundchannel_cancel is called after fundchannel_complete and we cancel the channel successfully. Then we must reconnect with the remote peer before fundchannel_start again.
  Like notify_disconnect when remote peer sends error? #2741 said, when the peer receive error message or when the peer deletes the channels, the peer will disconnect with the remote peer.
  The main reason for this is channel_set_owner(channel, NULL, false) moves responsibility for the connection to connectd not openingd. If we want to keep connection, rolling back from channeld to openingd is necessary.

Open Question

In f77d6c7 (Fix: Store the transaction(broadcast by txsend) into DB), I add the label TX_UNKNOWN
for the transaction broadcast by txsend.
I think maybe we can add optional string field for txsend command to specific the label. What do you think about it?

Unfinished

• Update document

• Add CHANGELOG

Note: 9ebb521 is duplicated with a commit of #2964 , just for making travis-ci happy

Thanks for @ZmnSCPxj and @niftynei's explanation, direction and help!

[ZmnSCPxj]

Looks OK to me, please just add documentation.

[trueptolemy]

@ZmnSCPxj Thank you! Now I complete the document.

[trueptolemy]

Add the check that the tx broadcast by bitcoind can be catched.

[trueptolemy]

Rebased and resolved the conflict.

[niftynei]

ack 67c15a5