permessage-deflate: make client/server_max_window_bits optional in the offer

[mikkel-kaj]

Problem

Connecting as a client to a server that rejects a permessage-deflate offer carrying client_max_window_bits/server_max_window_bits fails, and there is no way to leave those parameters out.

generateHeader() unconditionally appends ; server_max_window_bits=15; client_max_window_bits=15. 15 is the default window size in RFC 7692 (section 7.1.2), so advertising =15 conveys nothing the peer would not already assume — the parameters only carry meaning when you want a window smaller than 15 to save memory. Some servers and gateways are strict about the extension parameters they accept and reject an offer that includes them, and the library gives no way to suppress them.

Fix

Add a sendClientServerMaxWindowBits flag on WebSocketPerMessageDeflateOptions that gates emitting the two parameters.

• Defaults to true, so the generated header is identical for anyone who does not set it.

• Set it to false to send a bare permessage-deflate offer:

  ix::WebSocketPerMessageDeflateOptions opts(true, false, false, 15, 15, false);
  webSocket.setPerMessageDeflateOptions(opts);

• The new parameter is appended at the end of the constructor, so existing positional calls are unaffected.

• The header-parsing constructor now initializes the flag as well; it was left unset before.

Verification

Built the library (zlib backend) and exercised generateHeader() both ways:

default: Sec-WebSocket-Extensions: permessage-deflate; server_max_window_bits=15; client_max_window_bits=15
off:     Sec-WebSocket-Extensions: permessage-deflate

The default output matches the current header exactly; with the flag off the two parameters are gone. The existing per-message-deflate-codec test still passes.