fix(library): honor the log level a node is configured with

[osmaczko]

Description

A node's logLevel reaches chronicles: Waku.new passes it to logging.setupLog, which calls topics_registry.setLogLevel. Nothing reads it back. chronicles consults the runtime level only when compiled with chronicles_runtime_filtering, which defaults to off, so each statement's level is resolved at compile time and the configured value is accepted and ignored.

liblogosdelivery therefore logs everything from the compile-time level up and an application embedding it cannot quiet it. With "logLevel": "ERROR" in the node configuration you still get a steady stream of DBG/INF lines: kademlia record walks every few seconds, filter subscription maintenance, autonat probes, mesh peer checks and heartbeats.

Changes

library: enable chronicles runtime filtering

One define in library/nim.cfg. It goes there rather than in nix/default.nix so that every path that builds the library picks it up: the nix package flake consumers link, and the make liblogosdelivery targets behind the release assets and the Windows DLL. It also matches how apps/*/nim.cfg already configure chronicles, apps/wakucanary/nim.cfg with this same define and nothing else.

Behaviour does not change until an application sets a level. The runtime level is an Atomic[LogLevel] that zero-initializes to NONE and the gate is logStmtLevel >= activeLogLevel, so with nothing configured every statement passes exactly as it does today. Topic-annotated statements take the same path, with TopicState defaulting to Normal. The compile-time level remains the ceiling, so chroniclesLogLevel still decides what is available to select at runtime and existing overrides of it are unaffected.

Not included, deliberately: chronicles_sinks and chronicles_default_output_device, the pair logging.setupLogFormat needs before logFormat TEXT/JSON does anything. That is a separate defect, and enabling the dynamic device here would route every record logged before setupLogFormat runs through defaultDynamicWriter, which reports them on stderr as "log message not delivered" rather than printing them.

Issue

No issue in this repo. Reported downstream as logos-co/logos-chat-ui#37, where an embedding application's console is dominated by this output.

[osmaczko]

The red jobs here are a dependency resolution problem, not this change.

All five fail compiling apps/wakunode2/wakunode2.nim, apps/logos_delivery_node/logosdeliverynode.nim or tests/all_tests_waku.nim against chronos-4.2.3, at:

nimbledeps/pkgs2/chronos-4.2.3-.../chronos/apps/http/httpserver.nim(336, 11) Error: selector must be of an ordinal type, float or string

nimble.lock pins chronos 4.2.2, and the logs show the locked clone failing first with destination path '.../githubcom_statusimnimchronos_403410' already exists and is not an empty directory, the shared-pkgcache race the -j1 comment in ci.yml describes. The nimbledeps cache key hashes nimble.lock, and the restore path skips nimble setup, so once a cached tree has drifted to 4.2.3 it keeps being restored. build-docker-image fails the same way on #4055.

This change cannot reach those targets. library/nim.cfg is read only when compiling library/liblogosdelivery.nim, and make -j1 all builds wakunode2 before liblogosdelivery, so every failure happens before the library is compiled at all.

The jobs that do build the library all pass: x86_64-linux / liblogosdelivery, aarch64-darwin / liblogosdelivery, and build-windows, which runs make liblogosdelivery STATIC=0 and asserts the DLL exists.

Scope of what that verifies: the define compiles on the nix and make paths. Nothing here exercises the behaviour, since no test asserts on log output. That a configured logLevel now actually filters comes from reading topicsMatch and the runtime-filtering codegen in chronicles, and wants a running node to confirm.

[osmaczko]

Closing: we can get what we need downstream without changing this repo.

nix/default.nix already exposes chroniclesLogLevel, so a consumer can cap the compile-time level via .override and stop the flood at its own build, which is what we are doing. That leaves logLevel in a node's configuration still inert, but nothing on our side depends on selecting it at runtime today.

Leaving the observation here in case it is useful to someone: the config key is plumbed all the way to topics_registry.setLogLevel and has no effect, because chronicles_runtime_filtering defaults to off and no build path in the repo enables it for the library. The one-line change is in the history of this branch if anyone wants it later.

Unrelated to this PR, but visible in its CI: several jobs failed compiling against chronos-4.2.3 while nimble.lock pins 4.2.2, after the locked clone hit destination path ... already exists and is not an empty directory in the shared pkgcache. build-docker-image failed the same way on #4055. Since the nimbledeps cache key hashes nimble.lock and the restore path skips nimble setup, a drifted cached tree keeps being reused. Might be worth clearing that cache key.