merge coroot/logparser v1.4.2: JSON parser, pattern rate limit, level fixes

[mayankpande88]

Summary

Merges coroot/logparser main (v1.4.2) into this fork:

• a JSON log parser that extracts the message, level and attributes;
• multiline handling for JSON logs;
• a rate limit on pattern extraction under log storms;
• level fixes: MySQL/MariaDB [Note]/[System], trusting the level reported with an entry, and mongodb {"$date"} timestamps.

Please merge with "Create a merge commit", not squash. That keeps coroot's history, so the next sync only brings new commits, and keeps the commit node-agent pins (2d6d6c9) reachable from main.

Engineering detail

How the two sides were combined:

• NewParser takes both upstream's parseJson and limiter and this fork's SensitiveConfig. OnMsgCallbackF gets upstream's attributes argument.
• Levels and patterns still come from this fork's ParseStructuredLog (JSON and logfmt). With parseJson, a JSON log is emitted as its message, with the other fields as attributes, as upstream does.
• Over the rate limit, pattern extraction and sensitive-data detection are skipped, but the message is still passed to the callback under the sampled pattern hash. Upstream drops it, so this differs: a limit meant to cap CPU must not drop log records. TestParserRateLimit asserts this.
• Name clash: pattern.go's jsonMessageKeys/jsonLevelKeys are renamed to patternMessageKeys/patternLevelKeys, because json.go declares the same names.

Tests: go vet and go test ./... pass.

Local e2e: I built nudgebee/node-agent against this commit and ran it as a systemd service on a local Debian 12 VM (kernel 6.1), exporting logs over OTLP to a local OpenTelemetry collector.

• JSON log line ({"level":"error","msg":"payment failed","order_id":...,"trace_id":...,"span_id":...}): it arrived with body payment failed, severity error, attribute order_id, and the trace and span IDs set. The build against the previous commit sent the raw JSON line, without trace context.
• Pattern hash: the same in both builds.
• Error-line storm (about 59,000 lines in 30s): every line was counted. With the limiter at 100/s, 55,070 went under the sampled pattern; with no limiter, all went under their own single pattern.

[gemini-code-assist]

Code Review

This pull request introduces JSON log parsing capabilities to extract levels, messages, and attributes, integrates this parsing into the main parser with rate limiting, updates multiline log collection to handle JSON lines, and expands log level guessing for MySQL/MariaDB. Feedback on these changes highlights a performance concern regarding redundant double-parsing of JSON logs in Parser.inc. Additionally, potential bugs were identified in both multiline.go and json.go where CRLF line endings or trailing whitespace could cause JSON detection and parsing to fail due to strict suffix checks on the closing brace.