Was looking at #619 and realized that even after #612 we're still stopping the background processor before we disconnect_all_peers. Specifically, we tell LDK's background processor to stop via the same stop_sender that is used universally to stop ~everything (at the very top of the stop method). This could cause the background processor to exit pretty quickly, and before the call to disconnect_all_peers, which must happen before the background processor stops. Thus, we could still end up writing the final ChannelManager state after a peer update happens, in a hopefully-now-pretty-rare race.