Rebalancing needs overhaul

[bitromortac]

The rebalancing system needs an overhaul as the strategy of rebalancing channels one-by-one does not optimize for speed and optimal fees.

A new system should incorporate:

• an internal improved path-finding machinery that tracks failed and successful hops that can support several pathfinding heuristics
• should have an easy interface for specifying minimal and maximal rebalancing fees
• the expected future gain should be fed back into the pathfinding system
• it should be possible to give just an amount as an input.
• we should select the counterparty channel from a set of peers (i.e. rebalance candidates need to be viewed not on a per channel basis)
• to determine the channel to rebalance, we should be able to give only a node pubkey
• it should be possible to do rebalancing even if we have multiple channels to the sending conterparty (issue a warning)
• persist liquidity hints
• improve path finding heuristics: time penalty (average, hard blacklist)
• preference for certain counterparty channels
• discourage attempts with counterparties that often failed
• route is sane to use
• update tests
• after several rebalance attempts, discourage failing incoming nodes by incrementally blacklisting (this way more diverse paths should be generated)
• generate a rebalancing summary: what were the nodes that we could not reach, which neighboring nodes failed most of the time to conduct a payment to us (they provide bad incoming liquidity), show how much of the target amount we rebalanced
• rebalancing direction should be prioritized by inward/outward fees, then flow, then unbalancedness
• amount should be checked beforehand whether we can in principle rebalance with it