ftsb_redisearch: histogram RecordValue is data-raced under -workers >1 (corrupts percentiles + counts)

[fcostaoliveira]

Found during the 7-way review of #115.

benchmark_runner.go's recording loop calls l.totalHistogram.RecordValue(...) and the per-label histograms (writeHistogram, readHistogram, …) from every worker goroutine without a lock. hdrhistogram's RecordValue is not concurrency-safe. Under the default -workers 8 this races: go build -race reports ~13 data races on the RecordValue → setCountAtIndex path, and increments are lost.

Note detailedMapHistograms and perSecondHistograms are mutex-protected, but totalHistogram and the per-label histograms are not — an internal inconsistency.

Impact:

• Percentiles (OverallQuantiles.*) computed from these histograms can be wrong/under-populated under concurrency.
• TotalOps/overallOpsRate were also affected — but Fix pipeline command accounting: flush trailing window + exact TotalOps #115 fixed those specifically by moving them to an atomic counter. The percentiles remain exposed.

Fix options:

• Guard the shared histograms with a mutex on the record path (simple; adds contention to the hot loop), or
• Record into per-worker histograms and merge at the end (no hot-path contention; preferred).

[fcostaoliveira]

The 16-way review of #115 surfaced a second, distinct concurrency bug with the same root cause (the report() ticker goroutine leaking past wg.Wait() because the ticker is never Stop()ed):

• report() appends to the shared time-series slices (writeTs/readTs/readCursorTs/updateTs/deleteTs) while the shutdown path's GetTimeSeriesMap reads and sort.Sorts those same slices → a slice append-vs-sort data race (reported by -race alongside the histogram races here).

Both are rooted in the un-stopped report goroutine. A fix should Stop() the ticker / signal the reporter to exit before the final read, in addition to guarding the histograms (per-worker histograms + merge, or a lock).