askrene: opt-in circular (self-rebalance) routes in getroutes

[ksedgwic]

This adds an opt-in allow_circular parameter to askrene-getroutes. When set, source == destination requests a self-rebalance cycle -- a route that leaves the source, traverses the network, and returns -- for moving liquidity between one's own channels. Because the cycles come from the MCF solver, a single call can move liquidity out of several channels and into several others in one pass, rather than rebalancing one channel pair per attempt. Without the flag nothing changes: source == destination is still rejected with the same error as today, so existing callers are unaffected.

The change stays out of the solver. It uses the standard node-splitting construction from network flow: at the gossmap-localmods layer, the source keeps only its outgoing edges and a synthetic sink receives mirrored copies of its incoming edges, so the MCF sees an ordinary source-to-sink problem and the solver child runs unmodified. The commit messages have the details, including how the returned route represents the closing hop.

Motivation: rebalancing tools currently have to do their own routing for circular payments; this lets them use the same solver as everything else. We have been running this patch against live rebalance traffic on mainnet (and signet).

Tests cover the flag-off (unchanged) behavior, a deterministic synthetic cycle, mirror-scid collision handling, and a self-rebalance over a real gossmap snapshot.

Changelog-Added: JSON-RPC: askrene-getroutes has a new allow_circular parameter to request self-rebalance (source == destination) routes.

[ksedgwic]

@Lagrang3

[ksedgwic]

rebased, hoping for a good CI run ...

[Lagrang3]

This is an excellent PR!

• commits document to a great extend the changes introduced,
• python tests included,
• the changes are mostly nicely contained in a single function inject_circular_fake,
• the author added useful comments in the code,
• the documentation is excellent.

[Lagrang3]

We can be increasing the number of flags forever. That's why, I guess, Rusty preferred
to introduce these as auto layers. So I would prefer to adhere to that pattern.
Instead of a boolean option this would be a auto.allow_circular layer.

[Lagrang3]

In this section, isn't it better to have the following pattern: ?

if(node_id_eq(source, dest)){
    // log source==dest -> needs circular ...
    err = inject_circular_fake(...);
    if(err){
        // log needs circular but failed for reason: {err}
        return command_fail(...);
    }
    // log circular routing prepared ...
}

[Lagrang3]

I remember @daywalker90 raised a question about circular rebalancing using askrene-getroutes.
AFAIK a channel rebalance doesn't need to be reliable, we can afford many trials, but does need to be cheap in fees.

I would like to also point out that the primitive API already present in askrene allows for a circular rebalance
just like @ksedgwic has done here. The user would need to create a fake node, fake channels and so on and at the end
translate back into real network terms in order to build the onions.

My suggestion is to do two things:

1. Create a layer in askrene auto.optimize_fees to indicate the desire to optimize for fees. We don't necessarily need to implement the back-end immediately.
2. Create a new json rpc at a higher level (either a new plugin or appended to an existing plugin, it can also be added to the plugins repository) that uses askrene primitives to do a circular rebalance.