fix: count empty continuation frames toward the maxFragments limit

[LeSingh1]

Problem

The maxFragments limit in Receiver is intended to cap the number of
message fragments a peer can send before an error is raised with close
code 1008. However, the check was placed inside if (data.length) in
getData(), so zero-byte continuation frames were never counted
against the limit.

A peer could send one non-empty opening fragment followed by an
unbounded number of empty (payload-length = 0) continuation frames
(opcode 0x00, FIN = 0). Each frame is parsed in getInfo() and
getData() with O(1) work per frame, but the limit never fires.
This allows a remote endpoint to keep the receiver spinning through
startLoop indefinitely, constituting a denial-of-service vector
against any server or client that sets maxFragments.

The same gap existed in the decompress() callback for compressed
fragmented messages.

Fix

Introduce a _numFragments counter (initialized in the constructor and
reset in dataMessage() at the end of every message, alongside
_fragments). The counter is incremented once per data frame in
getData(), before branching on whether the frame is compressed or
whether the payload is non-empty. The two previous `_fragments.length

= _maxFragments` checks are removed; the single early check replaces
both uniformly.

The threshold semantics are preserved: the error fires when the
(_maxFragments + 1)-th frame arrives, matching the previous behaviour
for non-empty frames.

Changes

• lib/receiver.js — add _numFragments counter; move limit check to
  cover all data frames regardless of payload length or compression.
• test/receiver.test.js — add a test that sends maxFragments: 2
  with one non-empty opening fragment followed by two empty continuation
  frames and asserts the second empty frame triggers the error.

Test results

436 passing (1s)
receiver.js | 100% Stmts | 100% Branch | 100% Funcs | 100% Lines

[lpinca]

Empty fragments are simply discarded so they cause no memory retention problems. It also does not make sense to send them in the first place.

This allows a remote endpoint to keep the receiver spinning through
startLoop indefinitely, constituting a denial-of-service vector
against any server or client that sets maxFragments.

This is not a denial of service. The option was added to keep memory usage under control.

[lpinca]

Thank you anyway.

[lpinca]

On second thought this simplifies the code, so I'm good with it.