Use inbound SCID alias for blinded path creation

[TheBlueMatt]

When we generate a compact blinded path to ourselves, we currently use the real SCID of our channels to tell our peers where to forward to. This is fine for short-lived blinded paths where we expect the channel to still be around, but post-splicing this may spuriously invalidate blinded paths just because we spliced.

Instead, here, we default to using inbound SCID aliases where possible. We also avoid one more reference to the channel's internal FundingContext in channelmanager.rs.

[ldk-reviews-bot]

I've assigned @tankyleo 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.

[tnull]

LGTM, but regarding "We also avoid one more reference to the channel's
internal FundingContext in channelmanager.rs.", mind sharing some context on why this is an improvement?

[TheBlueMatt]

"We also avoid one more reference to the channel's
internal FundingContext in channelmanager.rs.", mind sharing some context on why this is an improvement?

FundingContext is an internal detail to a channel, channelmanager.rs should have no need to care at all that a channel's funding has changed, there's simply no reason for it, and more encapsulation of the channel would make channelmanager.rs way less error-prone.

[tnull]

FundingContext is an internal detail to a channel, channelmanager.rs should have no need to care at all that a channel's funding has changed, there's simply no reason for it, and more encapsulation of the channel would make channelmanager.rs way less error-prone.

Ah, I have to admit I also remembered that context when reviewing #3881 afterwards, as we try to reduce the occurrences of FundingScope there.

[tankyleo]

LGTM as long as we are positive nodes in the blinded path will not complain that we've given them an alias and not the real scid - I don't really see this explicitly written down in the spec, but maybe it is implied ?

[TheBlueMatt]

I assume its fine (the peer told us its an alias for the channel!), but we should probably update the spec to ensure this. Do you mind tackling that with a quick spec PR?