feat(node): allow configuration of logging through configuration file

[DSharifi]

closes #2498

also closes #2501

[claude]

Code Review

Two issues found:

1. Missing #[serde(default)] on log_config field — backward compatibility break

StartConfig::log_config is a required field with no #[serde(default)] annotation. Any existing TOML config file used with start-with-config-file that doesn't have a [log_config] section will fail to deserialize with missing field log_config.

Fix: Add #[serde(default)] and implement Default for LogConfig:

// In StartConfig:
#[serde(default)]
pub log_config: LogConfig,

// New impl:
impl Default for LogConfig {
    fn default() -> Self {
        Self {
            log_level: None,
            log_format: LogFormat::Plain,
        }
    }
}

2. env_filter silently ignores RUST_LOG when log_level is set in config

When log_level is set in the config file, EnvFilter::new(level.as_str()) creates a simple global filter (e.g., "INFO"), completely ignoring any RUST_LOG environment variable. This means operators lose the ability to do per-module filtering (e.g., RUST_LOG=mpc_node=debug,hyper=warn) when a config-level log_level is set.

This may be intentional, but it's worth noting — consider documenting this precedence behavior, or using EnvFilter::builder().with_default_directive(level.into()).from_env_lossy() to allow RUST_LOG to override specific modules while using the config level as a baseline.

⚠️ Issue #1 should be addressed before merge.

[DSharifi]

1. Missing #[serde(default)] on log_config field — backward compatibility break

That's fine. Toml file is not used in prod yet.

2. env_filter silently ignores RUST_LOG when log_level is set in config

That's intened. Env variables won't be able to be passed from launcher anyway in prod settings.

[barakeinav1]

why did you remove it?

[DSharifi]

See comment here
#2500 (comment)

[netrome]

Nice stuff, although I think the new variant loses some features of the existing env filter that would be nice to retain.

[netrome]

Why and when do we need these now? It doesn't seem to be on all tests?

[DSharifi]

See the diff for removed code. Previously we called init_logging (prod logggin) for tests. Since init_logging API changed I didn't want to litter all callsites with building a logconfig, instead reusing this crate which is good for logging/traces during tests.

[netrome]

Ah I see. I think some of these tests aren't testing the logs though and should run without it imo, but we can clean that up later.

[netrome]

Feels a bit weird to use an "env filter" when we're not using the env anymore.

Also, it's quite common with more advanced filters (like enabling debug for certain modules). It would be nice to support that with the config file as well, but that could be left as a follow-up.

[DSharifi]

it's there to not break nodes that are not in tee, and most providers that don't use toml file for configuring which we just recently introducd.

[DSharifi]

I added a comment to make it non optional in a follow up issue once only config file is supported for launch

[netrome]

Yeah makes sense.

[barakeinav1]

we are also losing the ability to set MPC for DEBUG while having the indexer as INFO.
approving, but we should have this as a follow-up issue.

[barakeinav1]

• Logging init is still deferred to run_mpc_node(), so config parsing errors before that point are unlogged. not sure it matters in practice.

approving