Add disable_peer_networking flag

[tankyleo]

    Add `disable_peer_networking` flag

    The motivating use case is a recovery from a stale channel backup: after
    the peer has force-closed the channel, and the commitment transaction
    has confirmed, the peer should update to the latest blockheight with the
    stale database without reconnecting to the peer.

    Note that this only recovers funds in the `to_remote` output of the
    commitment transaction; it does not recover any HTLC funds.

    Co-Authored-By: HAL 9000

[ldk-reviews-bot]

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tankyleo]

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

[tankyleo]

If the node reconnects to the peer with a stale database, we get a panic, which I think is the correct course of action here; that's been the core motivation for this offline flag.

[tnull]

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

Hmm, I honestly would prefer to directly go for the full recovery mode we planned for a bit. Do you think this is time critical, or can we add it for v0.9?

[tankyleo]

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

Hmm, I honestly would prefer to directly go for the full recovery mode we planned for a bit. Do you think this is time critical, or can we add it for v0.9?

Yes let's go for the full recovery mode (do you have an issue describing this?)

I think this can wait for 0.9, feel free to close this PR and we can re-open a separate proper recovery PR.

[tnull]

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

Hmm, I honestly would prefer to directly go for the full recovery mode we planned for a bit. Do you think this is time critical, or can we add it for v0.9?

Yes let's go for the full recovery mode (do you have an issue describing this?)

I think this can wait for 0.9, feel free to close this PR and we can re-open a separate proper recovery PR.

No issue so far, but what we discussed was to have a special mode on builder or a separate utility that you'd give all the information you have (seed, list of known prior peers, etc) and it would try to claw all funds back that are possible, i.e., do force-close recovery but also retrieve possible_v2_counterparty_closed_balance_spks, and also do iterative full scans for the onchain wallet etc pp.

Actually, let me see if i can do a quick draft.