Stale ChannelManager causes channel force-closures #4286

LDK currently has two sources of truth for channel data, in particular what commitment number a channel is on: the ChannelManager and the per-channel ChannelMonitors. If, on startup, a monitor is ahead of the corresponding channel data present in the manager, that channel will force-close. We've seen this happen in the wild.

We'd like to fix this issue by reducing reliance on regular persistence of the ChannelManager, and instead reconstructing (at least parts of) it using ChannelMonitor data on startup.

• Store important Channel data that is currently persisted in the ChannelManager in ChannelMonitors instead Store and check channel data in channel monitors #4218
• Reconstruct Channels from ChannelMonitors instead of the manager on startup Reload channelmanager with channel data from monitors #4151
• Reconstruct manager events queue from monitor data Store channel-associated events in monitor #4278
• Reconstruct forward HTLCs queues in the manager from monitor data
  • Reconstruct ChannelManager forwarded HTLCs maps from Channels #4227
  • Fix double-forward, prefer legacy forward maps #4289
  • Prevent HTLC double-forwards, prune forwarded onions #4303
  • Dedup InboundUpdateAdd::Forwarded data; fix PaymentForwarded fields #4405
  • #4227 Followups #4280
  • Address RAAMonitorUpdateBlockingAction not applied to downstream channels in during-startup replay #4458
  • Complete migration plan spanning 0.3 to 0.5: Fix double-forward, prefer legacy forward maps #4289 (comment))
  • (0.5) Deprecate legacy pending HTLC ChannelManager persistence #4359
• Reconstruct claimable payments in the manager from monitor data
  • Reconstruct ChannelManager::claimable_payments on startup #4462
• Reconstruct outbound payments in the manager from monitor data
• Fix edge cases around in-flight monitor updates currently stored in the manager
• Fix edge cases around channel data that does not yet have a corresponding monitor
• Persist in monitors that ChannelReady was exchanged to prevent disconnection on reestablish
• While fixing test failures in Reload channelmanager with channel data from monitors #4151, track follow-up items where more data will need to be persisted in monitors and/or new monitor update steps will be needed