`sign`er methods can panic if driven incorrectly

[sr-gi]

Some public methods can lead to panics if called under certain conditions. While some of this may be permanent errors that the app cannot recover from, therefore panic-ing, some others may be handleable best with an Error, making it easier to catch both for Rust and foreign languages.

Here's a list of the ones I've found so far so (as of v0.0.12) we can discuss which one fall into which group.

• KeysInterface
  • counterparty_pubkeys
  • counterparty_selected_contest_delay
  • holder_selected_contest_delay

All this panic due to calling unwrap on None for non-accepted channels.

ChannelMonitor::get_latest_holder_commitment_txn panics if called for non-accepted channels (?)
@devrandom mentioned this is changing for v0.0.13, so it may not apply after that.

ChannelManager::funding_transaction_generated panics if called for an already accepted channel.

May add more if I find any.

[TheBlueMatt]

ChannelManager::claim_funds mentions something similar as well. In general all the ChannelManager functions should at least handle double-calls for a given event, given there are races that make it hard to avoid on the client side.

[TheBlueMatt]

Dont have to fully solve this for 0.1.1, but we should at least hit the ChannelManager parts.

[TheBlueMatt]

ChannelManager parts done!

[TheBlueMatt]

Would be nice to remove/reduce these, and some of it is happening as a part of the splicing work, but no real reason to block 0.2 on this.