CLN's channel_state_changed notification used to emit the sentinel
value "unknown" for old_state when there was no previous state.
That value was deprecated in v25.05 and is last-supported in v26.04;
as of v26.06 the old_state field is simply omitted instead (see
doc/developers-guide/deprecated-features.md, entry
"channel_state_changed.old_state.unknown").
The notification handler unconditionally extracted old_state, which
throws Jsmn::TypeError when the field is absent. The throw was
caught by the surrounding handler, logged as Error
("Unexpected channel_state_changed payload: ..."), and then the
handler returned without taking action. Functional behavior was
unchanged compared to the legacy "unknown" path (both result in
no destruction event), but the new release variant produced noisy
Error log lines for every state-changed notification on nodes
running v26.06+.
Add an explicit has() check and leave old_state as the default
empty string when absent. The empty string will not match either
"CHANNELD_NORMAL" or "CHANNELD_AWAITING_LOCKIN", so the handler
falls through to the no-op return -- the same outcome the legacy
catch-and-log path produced, but silently.
This is the third and final commit of the v26.06 compatibility
PR (preceded by the Dowser and Matchmaker/ActiveProber commits).
This introduces a number of changes:
* We can no longer implicitly capture `this` in `[=]() { ... }`,
we have to explicitly capture it: `[=, this]() { ... }`.
* We added a newer version of the `AX_CXX_COMPILE_STDCXX` macro as
the stable Debian does not have the latest version yet, and it is
the latest version that has support for C++20.
