Fix --pipeline >1 panic and pipelined byte/label accounting

[fcostaoliveira]

Closes #113.

Problem

On the --pipeline N (N>1) path, sendFlatCmd/sendIfRequired/connectionProcessor threaded parallel scalar values through the flush, which caused several defects (the default pipeline=1 path was already correct):

1. Panic — pipeline mode was unusable. connectionProcessor reassigned cmds/times from sendFlatCmd (so they accumulated to pipeline) but replies was never grown, so the flush loop indexed replies[pos] out of range → index out of range [1] with length 1, crashing the worker goroutine.
2. Per-command TxBytes fabricated. The flush recorded a single scalar txBytesCount for every command in the batch, so TxBytes became Σ(pipeline × flushing-row bytes) instead of the sum of each command's bytes.
3. Per-command labels wrong. cmdType/cmdQueryId were per-flush scalars, so a mixed pipeline filed every command under the flushing command's label (wrong histogram grouping).
4. RxBytes always 0. sendFlatCmd passed a nil interface{} receiver to radix.Cmd, so replies were discarded and getRxLen always saw nil. (Its string/[]string branches were dead.)
5. READ_CURSOR label mismatch. The histogram switch matched case "CURSOR_READ" while the code emits READ_CURSOR, so cursor reads were dropped from readCursorHistogram.

Fix

Buffer each pipelined command as a pendingCmd that carries its own send time, sent-byte count, reply receiver, and labels. The flush then records one correct stat per command. Specifically:

• One []pendingCmd buffer per slot in connectionProcessor (no separate replies slice to fall out of sync).
• sendFlatCmd passes a *interface{} receiver so replies are captured; getRxLen sizes string/[]byte/[]interface{} (recursive)/int64, dereferencing *interface{}.
• Each stat is recorded with its own txBytes, latency, cmdType, and cmdQueryId.
• benchmark_runner histogram switch corrected to case "READ_CURSOR".

Validation (E2E against redis)

--pipeline 4	master	this branch
exit	2 — panic (index out of range)	0
keys ingested	8 (crashed)	2000
TxBytes	—	135780 (per-command)
RxBytes	—	2000 (was structurally 0)

At pipeline=1, TotalOps and TxBytes are byte-identical to master (2000 / 135780); RxBytes goes from 0 → 2000 (replies now counted).

Tests

• TestPipelineRecordsPerCommandTxAndDoesNotPanic — with pipeline=2, two buffered commands flush without panicking and record their own Tx ([100, 200]; the old code produced [200, 200] and, in the real call path, panicked).
• TestGetRxLen extended for []byte / []interface{} / int64 / *interface{}.
• Existing TX/RX byte counters are swapped: reported TxBytes/RxBytes (and their rates) are mirror-labeled #111/Fix swapped TX/RX byte counters (TxBytes/RxBytes mislabeled) #112 byte-accounting tests updated for the new sendFlatCmd signature and still pass.

Notes / out of scope

• Reply capture cost: the *interface{} receiver allocates per command (radix previously discarded replies). This restores the evidently-intended behavior (getRxLen predates this PR) and makes RxBytes meaningful. Negligible for the dominant ingest path (integer/OK replies); for large query replies it is more — can be gated behind a flag in a follow-up if it perturbs latency measurement.
• TotalOps 1-off at pipeline>1: pipelined commands share one completion time, so the last has ~0µs measured latency, which the HDR histogram (min=1) rejects — a pre-existing pipeline latency-accounting semantics issue, not introduced here (master crashed before it was observable).

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud