I asserted that DataDog/zstd exposes no way to set ZSTD_c_nbWorkers. That
is false: zstd_stream.go:291 has SetNbWorkers. The bench simply never
called it, so the zstd-cgo row was a one-worker baseline by omission, not
by constraint. zstd-cgo-mt is the same binding with it set, which makes
libzstd's multithreading reachable in-process instead of only through the
CLI. On a 274MiB tar: 389 MB/s at 1.02x cores for zstd-cgo against
2380 MB/s at 7.47x cores for zstd-cgo-mt.

Note the worker count cannot be 0. At the library level
ZSTD_c_nbWorkers=0 means *no* worker threads; the core detection behind
the CLI's -T0 lives in programs/zstdcli.c, not in libzstd. Passing 0
silently yields a single-threaded encoder, measured at 1.03x cores and
indistinguishable from the plain binding. It is set to GOMAXPROCS here,
matching what pgzip and klauspost's zstd default to. The MT variant is
registered only when the linked libzstd actually has threading, so a
library built without it records a skip rather than failing the run.

Also: the CLI became multi-threaded by default in v1.5.7
(meta/zstd#4211), capped at max(1, min(4, nbCores/4)), not "since
1.5.x". That bound matters -- on <= 1.5.6 a bare `zstd -{level}` really
was single-threaded, so a CI running an older CLI would not show the
problem this branch is correcting for.

…mode

- -T# default is ZSTDCLI_NBTHREADS_DEFAULT, based on logical cores
  (UTIL_countLogicalCores() / 4, since #4211), not physical cores.
- ZSTDMT_NBWORKERS_MAX is 64 on 32-bit and 256 on 64-bit, not 200.
- Benchmark mode uses 1 worker thread by default since 725a152.

Signed-off-by: YoungjuKim <[email protected]>