Handle async initial ChannelMonitor persistence failing on restart (tests)

https://github.com/lightningdevkit/rust-lightning/pull/1678

Host: ariard  -  PR author: TheBlueMatt

The PR branch HEAD was ba2a2ba at the time of this review club meeting.

Notes

  • Chain monitoring is one of the most critical piece of infrastructure of a Lightning implementation. In LDK, the current main components are ChannelMonitor, ChainMonitor and OnchainTxHandler.
  • The current modularity is the fruit of multiple refactors: #462, #649, #681
  • With #1678, more fine-grained types of results are introduced to improve the fault-tolerance of LDK nodes.

Questions

  1. What’s the complete set of actions managed by the ChannelMonitor component ?
  2. How ChannelMonitor is integrating with ChainMonitor and how this component is interfacing with the rest of the node component through chain::Watch ?
  3. What’s the purpose of the Persist trait ? Why data persistence is critical and what are the fund risks in face of storage failure, chain events or counterparty transactions confirmation ?
  4. This PR is building on top of #1106, which is removing the broadcast of the commitment transaction in case of permanent node failure ? Is this change presenting trade-offs ?
  5. This PR is introducing more fine-grained types of persist results: UpdateComplete, UpdateInProgress, PermanentFailure, what’s the difference of persistence processing they’re informing back to the interface methods caller ?
  6. What’s the difference between the watchtower and the monitor replicas ideas and how they would benefit from #1678 ?