Overview

This PR adds two new options, MAXCOUNT and MAXSIZE, to the XREAD and XREADGROUP stream commands. They cap the cumulative reply across all streams named in a single command: MAXCOUNT bounds the total number of entries returned, and MAXSIZE bounds the total reply size in bytes. Unlike the existing COUNT option — which limits entries on a per-stream basis — these new options apply a global budget for the whole command, giving clients a reliable way to bound a multi-stream read.

Problem Statement

XREAD/XREADGROUP accept multiple streams in one call, and COUNT only limits entries per stream. A read over N streams with COUNT C can therefore return up to N * C entries, and the total reply size is effectively unbounded — a single command can return a very large payload depending on how many streams match and how large each entry is.

For clients that need to bound the work and memory of a single round trip (e.g. fan-in consumers reading many streams, or latency-sensitive paths), there is no way today to say "give me at most K entries total" or "at most B bytes total" across all streams in one command. Working around this requires issuing per-stream reads and aggregating client-side, costing extra round trips.

Solution

Introduces two cumulative caps, applied across all streams in the command:

• XREAD [COUNT count] [MAXCOUNT maxcount] [MAXSIZE maxsize] [BLOCK milliseconds] STREAMS key [key ...] id [id ...]
• XREADGROUP GROUP group consumer [COUNT count] [MAXCOUNT maxcount] [MAXSIZE maxsize] [BLOCK milliseconds] [CLAIM min-idle-time] [NOACK] STREAMS key [key ...] id [id ...]

Semantics:

• MAXCOUNT caps the total number of entries returned across all streams. It must be a positive integer, and must be >= COUNT when both are given (since it is a cumulative cap over a per-stream limit). When COUNT is omitted, MAXCOUNT alone bounds the total.
• MAXSIZE caps the total reply size in bytes (tracked via c->net_output_bytes_curr_cmd). It must be a positive integer.
• At least one entry is always returned. The budget is never enforced until at least one entry has been emitted across the whole reply, so a single message larger than MAXSIZE is still returned rather than yielding an empty reply.
• Both caps work for new (>) reads and for history/PEL reads in XREADGROUP. For MAXSIZE, the limit is checked before delivering the next PEL/new entry, so a skipped entry is neither sent nor added to the consumer's PEL.

Implementation details:

MAXCOUNT is enforced in xreadCommand(): a running total_entries counter shrinks each stream's effective count to the remaining budget and stops scanning further streams once the cap is reached. MAXSIZE is enforced inside the emit loops of streamReplyWithRange() and streamReplyWithRangeFromConsumerPEL(), guarded by (emitted_before + arraylen) > 0 to preserve the "always serve one entry" exception. All existing callers (XRANGE, XCLAIM, XAUTOCLAIM, XINFO, and the consumer-PEL path) are migrated to the new struct form.

Examples

Given three streams, each with 100 entries:

MAXCOUNT caps the cumulative entry count (vs. per-stream COUNT):

> XREAD COUNT 50 STREAMS s1 s2 s3 0 0 0
# returns 150 entries total (50 per stream)

> XREAD COUNT 50 MAXCOUNT 80 STREAMS s1 s2 s3 0 0 0
# returns 80 entries total — capped across all streams

MAXCOUNT without COUNT — bounds the total directly, filling from the first stream onward:

> XREAD MAXCOUNT 7 STREAMS s1 s2 s3 0 0 0
# returns 7 entries total, all from s1

MAXSIZE bounds the reply size in bytes:

> XREAD MAXSIZE 200 STREAMS s1 s2 s3 0 0 0
# returns fewer entries than an unbounded read, but always >= 1

MAXSIZE always returns a single oversized message:

> XADD bigstream 1-1 f <5000-byte value>
> XREAD MAXSIZE 50 STREAMS bigstream 0
1) 1) "bigstream"
   2) 1) 1) "1-1"
         2) 1) "f"
            2) "<5000-byte value>"
# the single entry exceeds MAXSIZE but is still returned

Both together — whichever bound triggers first wins:

> XREAD MAXCOUNT 5 MAXSIZE 100000 STREAMS s1 s2 s3 0 0 0
# returns 5 entries (MAXCOUNT is the tighter bound)

XREADGROUP behaves identically for both new (>) reads and history/PEL reads, and the caps are honored after a blocking client is unblocked.

Backward Compatibility

This is a fully additive change. MAXCOUNT and MAXSIZE are new optional tokens recognized only within XREAD/XREADGROUP; when omitted, behavior is exactly as before. No existing command, argument, default, or reply format is modified, and no new command is introduced.