Merge ThreadContext (MDC) into event ContextData in Log4j2Logger

[merlimat]

Summary

Log4j2Logger.buildContextData builds the StringMap from only slog's contextAttrs and event attrs — it ignores the caller thread's log4j2 ThreadContext. Layouts using %X{key} and appenders that read event.getContextData().getValue(key) see nothing, even when the thread had MDC entries set at the time of the log call.

The standard log4j2 logger handles this via ContextDataInjector inside LogEventFactory. Slog's Log4j2Logger builds the MutableLogEvent manually for performance, and so must do the equivalent injection itself.

Reproduction (pre-fix)

ThreadContext.put("req", "abc123");
SLF4J_LOG.info("via SLF4J");        // → [req=abc123] via SLF4J
SLOG_LOG.info("via slog short");    // → [req=]       via slog short  ❌
SLOG_LOG.info().log("via slog event"); // → [req=]    via slog event  ❌

Fix

In Log4j2Logger.buildContextData, after clearing the thread-local StringMap, copy the current ThreadContext entries in first via ThreadContext.getImmutableContext().forEach(map::putValue), then layer slog's contextAttrs / event attrs / duration on top so slog overrides on key collision.

Performance

The fast path is preserved with one extra check:

MDC state	slog attrs	Cost added
Empty	None	One ThreadContext.isEmpty() check (single field read on the static map). Returns the same emptyFrozenContextData() singleton — no allocation, no map clear.
Empty	Some	Same as before (zero new cost in the inner loop).
Non-empty	Either	One getImmutableContext() (returns a backing-map reference, no copy) + a forEach loop to copy MDC entries into the existing thread-local StringMap. The copy has to happen anyway for the appender to see those entries.

ThreadContext.getImmutableContext() returns the actual immutable map reference from the underlying ThreadContextMap — it does not allocate a copy. Map.forEach iterates without per-entry allocation.

Tests

Added Log4j2MdcPropagationTest with 7 cases covering:

• MDC propagation through plain info(String) and fluent info().log(...) paths
• Override semantics: slog event attrs and derived-logger context attrs both override MDC on key collision
• MDC entries with no slog override are preserved
• slog event attrs do not leak into ThreadContext after the log call
• The empty-MDC + empty-attrs fast path still produces a non-null empty ContextData
• Pooled thread-local StringMap doesn't retain stale entries between calls

Without the fix, 4 of 7 tests fail. With it, all 7 pass.