Find multi part route

[t-bast]

Don't be fooled by the relative simplicity of the code, it took me many iterations to get it to that state, every small detail/heuristic plays an important role!

At first I wanted really hard to use Ford-Fulkerson. I'm convinced that finding a good way to split the payment is a circulation problem. But the devil lies in the details, and there are a lot of non-trivial issues when trying to adapt flow algorithms to MPP:

• fees are very hard to correctly handle, especially when using "augmenting paths" to rebalance
• flow algorithms tend to exploit edges' capacity to their maximum, whereas for MPP we ideally want to balance equally between paths
• randomizing a flow is non trivial (and randomization plays an important part in LN path-finding success IMO)
• converting a flow to a set of HTLCs that respect minimum-htlc-msat, maximum-htlc-msat and the total fee budget is much harder than it looks

In the end I decided to start with a simpler method, which is quite similar to Ford-Fulkerson but without rebalancing flow between already-found paths. Yen's k-shortest paths already provides a quite diverse set of paths, so I start with that and then greedily add HTLCs, while keeping track of the already-allocated HTLCs to avoid creating conflicting HTLCs. This is a very simple algorithm to follow and it works quite well on the mainnet graph. It will be a good first solution, and then we can experiment with different algorithms based on production A/B testing: this is the only good way of selecting the "right" algorithm for LN since we're blind to most of the flow information in the network.

I've done many tests on the mainnet graph with random nodes: this is what decided the default choices of parameters (minimum part amount, maximum number of parts). The 5th percentile for channel capacity is 31 000 sats, so choosing half that value as minimum amount guarantees we'll be able to leverage almost all paths. I've run many path-finding tests between random nodes in the network for an amount of 1.000.000 sats, and very rarely found a route with more than 5 parts, hence the choice 6 for the maximum number of parts.

I think it could make sense to allow mobile users to set max-parts themselves if the default value doesn't find a route for their payment: it may be slower but if it helps their payment get through, they can then reset the value to a more conservative one.