Add log spans using thread local storage in std

[joostjager]

This is a stripped-down version of #4223 where only the spans are stored in thread local storage. Contrary to storing the logger instance itself as well, this code change is fully optional and not interfering with the dev ux for no std users.

Example log output:

std-spans.log

node 2 TRACE [lightning::chain::channelmonitor:4263]   ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Updating ChannelMonitor with latest holder commitment transaction info [p:0355f8]
node 2 DEBUG [lightning::chain::chainmonitor:1451]     ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Persistence of ChannelMonitorUpdate id 5 completed [p:0355f8]
node 2 DEBUG [lightning::ln::channelmanager:11589]     ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Channel is open and awaiting update, resuming it [p:0355f8]
node 2 DEBUG [lightning::ln::channel:9488]             ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Restored monitor updating in channel d9d065715d1cbe419a5cddaa8b1b749e00acc5a747c7d08165767d1225770bcd resulting in no commitment update and an RAA, with commitment first [p:0355f8]
node 2 TRACE [lightning::ln::channelmanager:9838]      ch:d9d065 [Reconnect nodes B and C->handle_new_monitor_update] Handling channel resumption with an RAA, no commitment update, 0 pending forwards, 0 pending update_add_htlcs, not broadcasting funding, without channel ready, without announcement, without tx_signatures, without tx_abort [p:0355f8]
node 1 TRACE [lightning::ln::channel:8670]             ch:d9d065 [Reconnect nodes B and C] Updating HTLCs on receipt of RAA... [p:02888f]
node 1 TRACE [lightning::ln::channel:8703]             ch:d9d065 [Reconnect nodes B and C]  ...removing outbound AwaitingRemovedRemoteRevoke 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925 [p:02888f]
node 1 DEBUG [lightning::ln::channel:8962]             ch:d9d065 [Reconnect nodes B and C] Received a valid revoke_and_ack with no reply necessary. Holding monitor update 5. [p:02888f]
node 1 TRACE [lightning::ln::channelmanager:10054]     ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] ChannelMonitor updated to 5. 0 pending in-flight updates. [p:027f92]
node 1 TRACE [lightning::ln::channelmanager:10092]     ch:ae3367 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Channel is closed, applying 2 post-update actions [p:027f92]
node 1 DEBUG [lightning::ln::channelmanager:13975]     ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events] Unlocking monitor updating and updating monitor [p:02888f]
node 1 TRACE [lightning::chain::chainmonitor:1407]     ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor to id 5 [p:02888f]
node 1 INFO  [lightning::chain::channelmonitor:4226]   ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Applying update, bringing update_id from 4 to 5 with 1 change(s). [p:02888f]
node 1 TRACE [lightning::chain::channelmonitor:4311]   ch:d9d065 [Complete blocked ChannelMonitorUpdate->get_and_clear_pending_events->handle_new_monitor_update] Updating ChannelMonitor with commitment secret [p:02888f]

[ldk-reviews-bot]

I've assigned @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[codecov]

Codecov Report

❌ Patch coverage is 83.56164% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (cef001b) to head (ee9b3bb).

Files with missing lines	Patch %	Lines
lightning-macros/src/lib.rs	75.00%	5 Missing and 1 partial ⚠️
lightning/src/util/logger.rs	86.66%	0 Missing and 6 partials ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4287   +/-   ##
=======================================
  Coverage   86.59%   86.60%           
=======================================
  Files         158      158           
  Lines      102408   102479   +71     
  Branches   102408   102479   +71     
=======================================
+ Hits        88679    88748   +69     
  Misses      11310    11310           
- Partials     2419     2421    +2     

Flag	Coverage Δ
fuzzing	36.92% <100.00%> (+1.02%)	⬆️
tests	85.88% <83.56%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[joostjager]

Rebased and fixed a std/no_std compilation issue with the logging macros.

The problem was that Record::new had a conditional spans parameter only present with std, but #[cfg] checks in macros are evaluated in the calling crate's context, not lightning's. This caused argument count mismatches when crates like lightning-rapid-gossip-sync were compiled without std while lightning had it enabled.

Fixed by making Record::new always take a Spans type that is Vec<&'static str> with std and () (zero-sized) without, and adding a get_tls_spans() helper compiled inside lightning where the cfg correctly reflects its features.

[joostjager]

Taking this out of draft as I'm committed to adding span support, but putting it on hold while an alternative approach is being investigated: using proc-macros to transparently augment every method with an implicit logger parameter, which would allow passing the span stack through that invisible parameter instead of relying on TLS.