check the compressed stream under load

check the compressed stream under load

brisk_load.py read the stream as raw bytes and counted the chat lines in
them, which only works while nothing is compressed. With --encoding it
now asks for gzip or deflate, walks the chunked framing by hand and
inflates what comes out of it, so the bench covers the path that the
truncated chunk and the content coding fixes just touched.

Three counters are reported, and anything but zero means the stream is
coming apart: chunks that do not add up (short, or not closed by their
CRLF), compressed streams that stop inflating, and answers whose
Content-Encoding is not the coding that was asked for.

Seven runs of 150 registered players, plain, gzip and deflate, 60 and 90
seconds: all three counters stayed at zero, together with the write,
login and stream error counts. The coding is worth about a third of the
bytes on the wire (31%, repeatable across runs), and the chunked framing
costs 7.5% on top of the content when nothing is compressed.

The README says not to compare codings on the messages delivered: that
number swings by a factor of two between two runs of the same coding,
because the readers drain at different rates.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014M1jiEq9cHdE5SE5j6vFuE