fastwebsockets

Improves memory efficiency and reduces CPU overhead in the WebSocket writing and fragment processing logic. Shifted to ownership transfers and in-place mutations and reduced the number of heap allocations and eliminate unnecessary buffer zero-initializations. Operation After this PR Write Header Allocation + Copy Decode Text $O(1)$ Ownership transfer / Truncate

Issue #90 was closed with "blocking (synchronous) API is not a goal for fastwebsockets" — curious about the reasoning behind this. Is the core frame parser fundamentally tied to , or is it more of a scoping/maintenance decision? Asking because we run latency-sensitive WebSocket consumers on CPU-pinned threads with non-blocking + epoll busy-polling (no async runtime). The frame parsing performance of fastwebsockets is very appealing, but wrapping it in a single-threaded tokio runtime adds indirection we'd prefer to avoid. If the frame codec were generic over (with the async variant as a thin wrapper), it would open up fastwebsockets to a wider set of use cases without changing the async API. Happy to contribute if this is something you'd consider.