We relax constraints from the `channel_hint` through a linear refill.

We need to know the overall channel capacity, i.e., the amount_msat
that the channel was funded with, in order to relax the channel_hint
to refill over time.

We attach the hints to the plugin, so they get shared across multiple
payments.

Changelog-None

We're getting serious about how we manage the channel_hints, so let's
give them a proper home.

Suggested-by: Rusty Russell <@rustyrussell>

Suggested-by: Rusty Russell <@rustyrussell>

Keeping it in `amount_msat` made the comparisons easier, but it was
the wrong type for this.

If we have a large channel, fail to send through a small amount, and
then add a `channel_hint`, then it can happen that the call to
`channel_hint_set_update` is already late enough that it refills the
1msat we removed from the attempted amount, thus making the edge we
just excluded eligible again, which can lead into an infinite loop.

We slow down the updating of the channel_hints to once every
hysteresis timeout. This allows us to set tight constraints, while not
incurring in the accidental relaxation issue.

Making sure that we don't accidentally create an endless loop.

We were using `channel_hint` to temporarily tweak the graph inside of
a payment. However, these ad-hoc `channel_hints` are stickier than
their predecessors, in that they outlive the payment attempt itself,
and interfere with later ones.

Changelog-Changed: pay: Discarding an overly long or expensive route does not blocklist channels anymore.

I'm not sure how this ever worked, and it must've been racy: we
initiate a number of payments, then proceed to disconnect and
reconnect repeatedly. If a payment is attempted inbetween the
`disconnect` and `connect` the payment will fail. Removing it since it
most likely was just a sledgehammer test that we didn't know how to
fine-tune.

Changelog-None

It was failing because the channel_hint from one attempt would prevent
us from retrying. By changing the amounts so that the channel_hints do
not concern them (value smaller than estimate) we can make things work
as before again.

We were ignoring more reliable information because of the
stricter-is-better logic. This meant that we were also ignoring local
channel information, despite knowing better.

By simplifying the logic to pick the one with the newer timestamp we
ensure that later observations always trump earlier ones. There is a
bit of interplay between the relaxation of the constraints updating
the timestamp, and comparing to real observation timestamps, but that
should not impact us for local channels.

This commit fixes a "FIXME: This is slow" in the pay plugin. For
nodes with many channels this is a tremendous improvement in pay
performance. PR ElementsProject#7611 improves payment performance from 15 seconds to
13.5 seconds on one of our nodes. This commit improves payment
performance from 13.5 seconds to 5.7 seconds.

Changelog-Fixed: Improved pathfinding speed for large nodes.