keep websocket compression state across interleaved control frames

[arshsmith1]

What do these changes do?

When a permessage-deflate message is split across several frames, a peer may interleave a control frame (ping/pong/close) between the fragments (RFC 6455 §5.4). The reader uses _frame_fin to spot the start of a new message and (re)latch the per-message compression flag, but control frames always carry FIN, so an interleaved one makes the following continuation look like a fresh message and clears that flag. The continuation is then handled as uncompressed: raw deflate bytes are delivered for a binary message, or a UTF-8 error closes the connection for a text one.

The fix lets only data frames advance that tracker, so control frames stay transparent to the message framing and the compression state carries across them. The added test feeds a compressed first fragment, a ping, then the continuation and checks the binary message still decompresses.

Are there changes in behavior for the user?

No public API change. A compressed message that previously came back corrupted (or dropped the connection) when a control frame landed mid-message now decodes correctly.

Is it a substantial burden for the maintainers to support this?

No, it is a few lines in the reader plus one regression test.

Related issue number

N/A

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder