Provide Utilities to Persist NetworkGraph and Scorer

[ConorOkus]

We currently don't persist the NetworkGraph or Scorer data at all, leaving it up to users to implement this. It would be nice if our existing wrappers did this for users, likely via the BackgroundProcessor.

[jurvis]

hi @ConorOkus, I will like to take a look into working on this! 😄

I just watched the Creating a Sample Lightning Node with LDK video you did with @valentinewallace and it looks like it is deliberate design for developers to bring their own persistence solution for NetworkGraph and Scorer.

Is the thinking here to persist NetworkGraph and Scorer automatically like how we do for ChannelManager in BackgroundProcessor?

[TheBlueMatt]

Is the thinking here to persist NetworkGraph and Scorer automatically like how we do for ChannelManager in BackgroundProcessor?

Yep! Note that we already have access to the network graph via net_graph_msg_handler...network_graph() which we use to call remove_stale_channels regularly, we just have to also persist it occasionally.

[jurvis]

@TheBlueMatt is there still a desire to work on persisting Scorer? I started playing around with seeing how we may implement it and it looks like we will need to add a parameter to BackgroundProcessor::start to have access to the scorer; unless there's something I'm missing?

[TheBlueMatt]

Yes, I think it makes sense to move that way. We currently do it by hand in the sample, but it'd be nice if the background processor had an Option<>al scorer and could persist that. We'll need to bound it by Writeable instead of Score, I believe, though we could do both but bindings will be sad about that (or we could do a supertrait that is WriteableScore that is auto-implemented for everything that implements Score and Writeable).

[jurvis]

@TheBlueMatt sounds good. I have a draft implementation that uses LockableScore but I'll work on creating the WriteableScore super-trait. Hope to have something by Sunday. Thanks for the context!

[tnull]

It seems this was fully addressed by #1376 and #1416. Feel free to reopen if I'm missing something.