Askrene: an EXPERIMENTAL MCF plugin and infrastructure

[rustyrussell]

(Builds on #7495)

This steals the min-cost-flow implementation from renepay, neatens it up for standalone use, and wraps it in an API. At the heart of the API is "getroutes", but much of the API concerns managing layers: these contain additional information about topology and capacity of channels.

It doesn't do very much by itself, but it does making building a pay plugin much simpler, and it makes testing (and benchmarking) simpler too.

[Lagrang3]

it seems that this builds on top of #7495 as well.

[Lagrang3]

Very nice that you added helpers gossmap_chan_htlc_max, gossmap_chan_htlc_min, amount_msat_min and amount_msat_max.

Also the plugin data field, was very much needed. I don't see any plugin yet using this,
but I will start using it right away in renepay.

[rustyrussell]

it seems that this builds on top of #7495 as well.

Oops, typo! Fixed.

[Lagrang3]

The schema for askrene-age is missing.

[rustyrussell]

OK, merged those fixes, thanks!

[Lagrang3]

Instead of calling plugin_set_data here, why not pass the data as argument to plugin_main?

It is not clear to me what happens if I put that set data statement in init but also pass a data pointer in plugin_main. One of the two would come last and override the first. How can we avoid the user shooting himself on the foot?
IDK, maybe plugin_set_data should be kept static, and allow the user to set the data through the plugin_main API.

[rustyrussell]

It would override if you did both.

But the problem is that you should really do setup before allocating, so if you want to allocate it's awkward to do it before calling plugin_main. For example, leak detection setup.

Perhaps the main argument was the error, and we should have used this in init for all plugins? Any significant plugin has a main function anyway?

[Lagrang3]

I like the idea of the layers to isolate payment specific information. It makes good building blocks for a payment plugin.
I was thinking a payment plugin could have global and private layers of information: global layers would contain constraints that are relevant to any payment and private will be those bounded to a unique payment.

[Lagrang3]

ACK

[rustyrussell]

I like the idea of the layers to isolate payment specific information. It makes good building blocks for a payment plugin. I was thinking a payment plugin could have global and private layers of information: global layers would contain constraints that are relevant to any payment and private will be those bounded to a unique payment.

Yes, I was thinking a "pay" layer which all/any local pay plugins will contribute to, and "tmp.<pluginname." layers for local payment information.

This prompts the question: who maintains the pay layer? In particular, who ages it, and does anyone save and restore it across restarts?

Maybe we should change the age command to set a threshold? Or even not age layers, supply a threshold on the getroutes() command, which discards old modifications for that particular query? (If we want a different age for each layer, this gets a bit more complex though).

I think we can revisit this later, though, once we have experience.