The ChannelCreator Planner asserts
min_channel + min_remaining <= max_channel at construction, where
min_remaining = 2 * min_channel + 20000 sats. Option validation
only enforced max_channel >= 2 * min_channel, so a pair such as
min-channel=1000000 max-channel=2000000 passed startup and aborted
the plugin on the first channel-creation run (#147). The old 2x
clamp never prevented the crash: any pair it adjusted still
violated the planner precondition.
AmountSettingsHandler now enforces the precondition directly. On
conflict it keeps max-channel, which sets typical open size, and
lowers min-channel to the largest fitting value, logging a warning.
A max-channel too low for even the smallest permitted min-channel
is raised.
ChannelCreator::Manager also re-checks both planner preconditions
before constructing the Planner and skips the creation cycle with a
log line instead of aborting. This covers the sibling assert
min_amount * 2 <= total, which fails when onchain funds change
between the decider's trigger and the creator's run (#137).
Introduces the mechanism for runtime-mutable plugin options: an option
marked dynamic can be changed via `lightning-cli setconfig <name> <val>`
without restarting clboss or lightningd. No option opts in yet -- this
is the foundation (the rebalancer mode selector is the first consumer).
- Boss::Msg::ManifestOption gains a bool dynamic field (default false,
preserving the existing startup-only contract).
- 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)
from Msg::ManifestOption events, then handles incoming setconfig
CommandRequests: it validates the named option is registered and
dynamic, and re-raises a fresh Msg::Option on the bus, so existing
option handlers re-apply the new value transparently.
Because Msg::Option is now re-emitted at runtime (not only during init),
subscribers must filter by name and tolerate post-init arrival.
AmountSettingsHandler gains an `if (!settings) return` guard: it moves
`settings` away at EndOfOptions, so a later Msg::Option for an unrelated
name must be dropped -- this also fixes a latent assert(settings) crash
that any post-EndOfOptions Msg::Option would have tripped.
Contract documented in SetConfigHandler.hpp: lightningd delivers
Int/Bool/Flag option values as JSON primitives at startup but as JSON
strings at setconfig time, so dynamic-option handlers must accept both
Jsmn shapes.
