Adds periodic askrene-age against the persistent clboss-xrebalance
layer so capacity constraints written by inform_channel_constrained
do not accumulate forever. Mirrors FundsMover's age_clboss_layer:
fires on Msg::TimerRandomHourly, logs num_removed at Debug, and
catches RpcError with -32601 stayed at Debug (graceful degradation
on CLN without askrene-age) while other codes promote to Warn so
sustained aging failure is visible.
The aging cutoff is controlled by a new plugin option,
clboss-xrebalance-age-secs, default 3600 (1h) to match FundsMover's
production value. Operators on networks with slower flows (signet)
are expected to widen this; the right value is empirical and will
be tuned after observation.
The option is registered dynamic=true so the window is mutable at
runtime via:
lightning-cli setconfig clboss-xrebalance-age-secs <secs>
No clboss / lightningd restart required.
To support that, three small infrastructure pieces:
* Boss::Msg::ManifestOption gains a bool dynamic field (default
false; preserves existing behavior).
* Boss::Mod::Manifester emits the per-option dynamic flag in the
getmanifest response, so lightningd knows to forward setconfig
for that option.
* New Boss::Mod::SetConfigHandler module records (name -> dynamic
flag) from Msg::ManifestOption events, then handles incoming
Msg::CommandRequest where command == "setconfig" by validating
the named option is registered + dynamic and re-raising a fresh
Msg::Option on the bus. Existing option handlers re-apply the
new value transparently.
Contract for any future opt-in to dynamic: at startup lightningd
encodes Int / Bool / Flag option values as JSON primitives, but at
setconfig time it encodes them as JSON strings. Handlers for
dynamic options must accept both Jsmn shapes. The XMoveFunds
option handler does this; the contract is documented in
SetConfigHandler's header comment so future modules can opt in
safely.
Adds Boss/Mod/XMoveFunds/Main.{hpp,cpp} and registers a new RPC
command `clboss-xmovefunds`. This is the lowest-level primitive
that the upcoming xrebalance algorithm will sit on top of: the
caller hands it an explicit set of source channels (drain
candidates), destination channels (fill candidates), an amount,
and optional knobs, and the module will eventually drive an
askrene-getroutes call (circular mode) and an optional sendpay.
The module follows the pimpl + Impl pattern already used by
FundsMover and is installed in Boss/Mod/all.cpp alongside the
existing rebalance machinery.
API surface
Each of source_scid and dest_scid may be either a single scid
string or a JSON array of scid strings. The single-channel form
is convenient for hand-typed RPC calls; the array form is what
the xrebalance algorithm will use to express multi-source /
multi-dest tier selection. parse_scid_list() in the
implementation handles both shapes uniformly.
Named parameters:
source_scid scid string or array -- channels whose us->peer
direction stays unmasked. Required.
dest_scid scid string or array -- channels whose peer->us
direction stays unmasked. Required.
amount_msat integer -- total amount to move. Required.
maxfee_msat integer. Defaults to 5000 ppm of amount_msat,
floored at 1000 msat.
maxparts integer. Defaults to 10.
execute boolean. Defaults to false; when false, the
route is computed and reported but not sent.
The manifest help text spells out the array shape with concrete
examples so anyone running `lightning-cli help clboss-xmovefunds`
sees the full surface without having to read the code.
