In order to avoid naming collisions with LDK's `Event` type, we rename
`lightning-liquidity`'s `Event` to `LiquidityEvent`. To minimize furhter
churn on the upcoming renaming changes, we also `impl From X for
LiquidityEvent` for the protocol-specific event variants, which also
allows us to reduce some boilerplate while enqueuing.
As we're not testing with `cfg(lsps1_service)`, the builds broke during
previous refactoring. This isn't bad as we're looking to completely
overhaul / rewrite LSPS1 service soon, but until then we fix this
pre-existing breakage to make sure following changes make sense.
Recently, LSPS0, 1, and 2 were upstreamed as bLIP-50, 51, and 52,
respectively. Here, we
1. start linking to the bLIPs instead of the LSP spec repository, which
is likely going to be deprecated.
2. start consistently citing the specs as `bLIP-5X / LSPSX` to avoid any
confusions and to potentially initiate a process in which the LSP
specs will be referred to by their bLIP number rather than their LSPS
number (especially given that any upcoming specs by the LSP
spec group will directly be drafted as bLIPs going forward).
.. we planned to use the BP for some more advanced integration tests, but we
haven't actually implemented them as of now. Here we drop the
unnecessary dev-dependency for now.
To trigger message processing, we previously had the user set a callback
to `PeerManager::process_events` via an `Fn()` callback. This is however
not supported by `c_bindings`.
Here, we therefore introduce as `ProcessMesssagesCallback` trait that
can be used via `LiquidityManager::set_process_msgs_callback_fn`, which
is exposed in `c_bindings`.
Previously, we wouldn't set the field as we aren't yet making use of it.
Here, we start setting the field. To this end, we make `best_block` an
`RwLock<Option<BestBlock>>` rather than `Option<RwLock<BestBlock>>`.
When a peer misbehaves/sends bogus data we reply with an error message
and insert it to the ignored list.
Here, we avoid having this list grow unboundedly over time by removing
peers again once they disconnect, allowing them a second chance upon
reconnection.
While LDK/`ChannelManager` should already introduce an upper-bound on
the number of peers, here we assert that our `PeerState` map can't
grow unboundedly. To this end, we simply return an `Internal error` and
abort when we would hit the limit of 100000 peers.
We include any `OutboundJITChannel` that has not made it further than
`PendingInitialPayment` in the per-peer request limit, and will of
course prune it once it expires.
In addition to pruning expired requests on peer disconnection we also
regularly prune for all peers on block connection, and also remove the
entire `PeerState` if it's empty after pruning (i.e., has no pending
requsts or in-flight channels left).
We add a size limit on the event queue, after which we'll just start
dropping events to ensure we could never OOM.
Additionally, we document the requirement that users need to handle
generated events ASAP.
We upstream the `lightning-liquidity` into the `rust-lightning`
workspace.
Files are copied over as per commit c80eb75f5a31bea5c2b73e41c50ca382ec0020f8.
