ftsb_redisearch: reply capture (#114) unmarshals full RESP reply inside the measured latency window (inflates FT.SEARCH latency)

[fcostaoliveira]

Found during the 7-way review of #115; the behavior was introduced by #114.

To make RxBytes meaningful, #114 changed the command receiver from a bare nil interface{} (radix discards the reply — zero alloc, no reflection) to reply := new(interface{}) (radix fully unmarshals the RESP reply into nested Go values via reflection). That unmarshal happens inside client.Do(), which is inside the measured latency window (endT - sendT).

Impact:

• WRITE / simple replies (+OK, integers): ~1 small alloc, negligible.
• FT.SEARCH / FT.AGGREGATE returning K docs × F fields: O(K·F) reflect-driven allocations per query inside the window — order ~10µs of client-side CPU charged as query latency, plus GC pressure that competes with load generation. This lands exactly on the read/vector workloads RediSearch benchmarks exist to measure, so latency/throughput numbers straddling the Fix --pipeline >1 panic and pipelined byte/label accounting #114 merge are not comparable for those workloads.
• getRxLen also reconstructs RxBytes by walking the unmarshaled structure and misses RESP framing ($<len>\r\n, *<n>\r\n), so it undercounts true wire bytes.

Fix options:

• Gate reply capture behind a flag (default off) so latency runs use the discard path, or
• (preferred) replace the generic *interface{} receiver with a custom resp.Unmarshaler that discards while counting actual wire bytes — fixes both the in-window overhead and getRxLen's framing inaccuracy in one move.