Description
We had an issue where a user's scoring parameters were set to strongly prefer one channel, but in practice it never actually had any liquidity. As a result, they ended up in somewhat of a loop - once every $SCORER_HALF_LIFE, they'd suddenly be retrying the channel again, and would have to retry it again each time a lower-value payment came through, until eventually the liquidity bounds would be very low, and then it would sit still for a $SCORER_HALF_LIFE, before the process started anew.
While we don't want to remove the half-life, the fact that the liquidity bounds jump by a rather large amount at each half-life is a problem, causing a number of retries along the given channel until we finally get the bounds low enough to stop using it. Instead, we really need to find a way to make the bounds updates more linear.
Sadly, currently we apply half-lives while doing routing, which limits us to ensuring we're doing very fast things (eg shifting, not multiplying) but if we instead did scorer update passes on a few-minute timer and updating all the bounds as we go, we could drop the during-scoring updates and also be much more linear (and slower).