API Updates

• A ChannelManager::send_payment_with_route was (re-)added, with semantics
  similar to ChannelManager::send_payment (rather than like the pre-0.1
  send_payent_with_route, #3534).
• RawBolt11Invoice::{to,from}_raw were added (#3549).

Bug Fixes

• HTLCs which were forwarded where the inbound edge times out within the next
  three blocks will have the inbound HTLC failed backwards irrespective of the
  status of the outbound HTLC. This avoids the peer force-closing the channel
  (and claiming the inbound edge HTLC on-chain) even if we have not yet managed
  to claim the outbound edge on chain (#3556).
• On restart, replay of Event::SpendableOutputs could have caused
  OutputSweeper to generate double-spending transactions, making it unable to
  claim any delayed claims. This was resolved by retaining old claims for more
  than four weeks after they are claimed on-chain to detect replays (#3559).
• Fixed the additional feerate we will pay each time we RBF on-chain claims to
  match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB (#3457).
• Fixed a cased where a custom Router which returns an invalid Route,
  provided to ChannelManager, can result in an outbound payment remaining
  pending forever despite no HTLCs being pending (#3531).

Security

0.1.1 fixes a denial-of-service vulnerability allowing channel counterparties to
cause force-closure of unrelated channels.

• If a malicious channel counterparty force-closes a channel, broadcasting a
  revoked commitment transaction while the channel at closure time included
  multiple non-dust forwarded outbound HTLCs with identical payment hashes and
  amounts, failure to fail the HTLCs backwards could cause the channels on
  which we recieved the corresponding inbound HTLCs to be force-closed. Note
  that we'll receive, at a minimum, the malicious counterparty's reserve value
  when they broadcast the stale commitment (#3556). Thanks to Matt Morehouse for
  reporting this issue.