GeezerVison

Summary

Fixes #498 (LOGGING-005). At LogLevel.debug, both backends logged one Fetched chunk of size: N … record per fetchChunk call, which DBSQLOperation shares across backends. They logged nothing when a result set was torn down, and LogLevel had no trace member to move the per-fetch record to.

This adds LogLevel.trace and moves the per-fetch record to it. At debug, each result set now logs one summary when it is closed or cancelled, including when the server ends the statement, for example Result set of operation with id: … closed (rows: 2, fetches: 2). A result set abandoned after a few rows still gets one. The counts come from two counters that fetchChunk increments.

winston's default npm levels have no trace, and a transport set to an unknown level drops every record. DBSQLLogger now uses the npm levels plus trace (between debug and silly), so logger.logger.silly() and the other level methods still work. Custom IDBSQLLogger implementations receive trace records only while their getLevel() returns LogLevel.trace. Loggers without getLevel() never receive them. Kernel trace records are now forwarded as LogLevel.trace under the same rule.

Testing

• Unit tests cover the debug, trace and partial-read phases of the spec, cancel and repeated close, operations without a result set, loggers without getLevel(), DBSQLLogger at trace, and the kernel bridge mapping. npm test (1543 passing), lint, prettier, type-check and build pass.
• Live warehouse, both backends: on origin/main, debug_full logs 5 per-fetch debug records and 0 summaries. On this branch it logs 0 per-fetch records and 1 summary, debug_partial (2 of 100 rows) logs 1 summary, and trace_full logs 5 per-fetch trace records plus 1 summary. Cancel then close logs one summary. The existing batched-fetch, iterator, CloudFetch and kernel logging e2e specs pass.
• Perf (medians, fresh processes, alternating order): with the default logger level, 200k one-row fetches take 237 ms on main and 119 ms here, since the per-fetch winston call is gone. A 20M-row drain in 10k-row chunks takes 535.6 ms vs 535.7 ms. Live drains (5 runs each) stay within noise: Thrift 2M rows 5367 vs 5450 ms, kernel 2M rows 4667 vs 4615 ms.

This pull request and its description were written by Isaac.