Goal

As a support engineer analyzing access logs after the fact, I need per-operation thread pool context alongside each operation's STAT line so I can correlate individual operation latency with overall pool saturation at the moment that operation ran.

nsslapd-statlog-level is a bitmask controlling per-operation STAT lines in the access log. Currently only LDAP_STAT_READ_INDEX (0x01) is defined. A reserved slot LDAP_STAT_FREE_1 (0x02) exists in proto-slap.h.

Repurpose it as LDAP_STAT_THREAD_POOL. When enabled, each operation's access log STAT line includes busy_workers=N/M queue_depth=N. In JSON format: stat_pool_busy, stat_pool_max, stat_pool_queue fields. This answers the question "were the workers saturated when this specific operation was slow?"

Currently STAT level works only for searches, so we would need to extend it to other operations.

The setting is changeable at runtime without restart. Cost when disabled: one bitmask comparison. Cost when enabled: 2–3 atomic loads plus one log write per operation.

Acceptance criteria

• Verify that setting nsslapd-statlog-level: 0x02 produces STAT lines with busy_workers and queue_depth for all operation types (SEARCH, BIND, MOD, ADD, DEL, EXTOP), not just SEARCH
• Verify STAT output works in both plain-text and JSON access log formats
• Verify the setting can be changed at runtime via dsconf without restarting the server
• Verify setting nsslapd-statlog-level: 0 produces no STAT output
• Verify combining flags (0x03) produces both index stats and thread pool stats