`historical_estimated_payment_success_probability` exposes the
historical success probability estimator publicly, but only allows
fetching data from channels where we have sufficient information.
In the previous commit,
`live_estimated_payment_success_probability` was added to enable
querying the live bounds success probability estimator.
Sadly, while the historical success probability estimator falls
back to the live probability estimator, it does so with a different
final parameter to `success_probability`, making
`live_estimated_payment_success_probability` not useful for
calculating the actual historical model output when we have
insufficient data.
Instead, here, we add a new parameter to
`historical_estimated_payment_success_probability` which
determines whether it will return fallback data from the live
model instead.
We already expose the estimated success probability from the
historical liquidity bounds from
`historical_estimated_payment_success_probability`, but we don't
do that for the live liquidity bounds.
Here we add a `live_estimated_payment_success_probability` which
exposes the probability result from the live liquidity bounds as
well.
Our current architecture requires `GossipVerifier`'s type signature to
include a circular reference to itself. Previously, we directly gave
that as `Self`, which however did not work when setting it dynamically
under all circumstances. Here we take `Self` by `Arc` mitigate this
issue.
A recent change accidentally inverted the returned monitor update for
the case where an update is applied after the channel has been closed.
This commit corrects that mistake.
We want to remove this before release so that we can work on a way to
not persist this but rather get it from other persisted data and just
free up the TLV.
Note that the "added in 0.0.124" comment was incorrect as it was
actually added in #3137 but the comment was stale so it's safe to remove.
1. InteractiveTxConstructorArgs is introduced to act as a single, more
readable input to InteractiveTxConstructor::new().
2. Various documentation updates.
For now this is unneeded as we do not provide any inputs as channel
acceptor and we do not allow creating outbound channels yet. It will
be re-added when that functionality is introduced.
If a peer creates a channel with us which never reaches the funding
stage (or never gets any commitment updates after creation), we'll
avoid inserting the `update_id` into
`closed_channel_monitor_update_ids` at runtime to avoid keeping a
`PeerState` entry around for no reason. However, on startup we
still create a `ChannelMonitorUpdate` with a `ChannelForceClosed`
update step to ensure the `ChannelMonitor` is locked and shut down.
This is pretty redundant, and results in a bunch of on-startup
`ChannelMonitorUpdate`s for any old but non-archived
`ChannelMonitor`s. Instead, here, we check if a `ChannelMonitor`
already saw a `ChannelForceClosed` update step before we generate
the on-startup `ChannelMonitorUpdate`.
This also allows us to skip the `closed_channel_monitor_update_ids`
insertion as we can be confident we'll never have a
`ChannelMonitorUpdate` for this channel at all.
