One of the recurring things we get asked for is "why was this channel closed?"
to which we usually just point to logs, that may not be present anymore due to
a restart. @ZmnSCPxj proposed adding a closure reason in [#4020] that'd
contain the cause of a channel closure (or more generally a state change) to
the listpeers result and to the channel_state_changed hook. I think this
could go a long way towards helping users perform cause analysis for any
unexpected closure.

Open Questions

• What state changes should be covered? Open, collaborative close,
  unilateral close, feerate adjustment, HTLC addition / removal. Arguably
  the latter two might be too detailed and cause a lot of overhead /
  noise in the status listing.
• Format of the information
• Should the information be persisted across restarts? If yes I'd argue
  we should create a single chanenl_state_change table that covers all
  possible fields, and not multiple tables.
• Would a state change history be desirable, or could that result in too
  much overhead (feerate adjustments, HTLC operations, ...)