websocket ssl errors

[totaam]

This bug was being triggered by the unit tests, unfortunately the whole test class was being silenced because of an environment error which has now been fixed.
Likely culprit: #3313

• server:

xpra start --no-daemon :100  -d http,ssl,ws,websocket \
    --bind-tcp=0.0.0.0:10000 \
    --bind-ws=0.0.0.0:10001

• client fails without --ssl-server-verify-mode=none:

Error: read on ws socket: 127.0.0.1:55382 <- 127.0.0.1:10001 failed: <class 'RuntimeError'>
Traceback (most recent call last):
  File "/usr/lib64/python3.11/site-packages/xpra/net/protocol/socket_handler.py", line 666, in _io_thread_loop
    while not self._closed and callback():
                               ^^^^^^^^^^
  File "/usr/lib64/python3.11/site-packages/xpra/net/protocol/socket_handler.py", line 760, in _read
    self._process_read(buf)
  File "/usr/lib64/python3.11/site-packages/xpra/net/websockets/protocol.py", line 112, in parse_ws_frame
    raise RuntimeError(f"cannot handle fragmented {op} frames")
RuntimeError: cannot handle fragmented 13 frames
Connection failed

The improved unit tests show:

RuntimeError: 2 errors testing ssl sockets:
* failed to connect to   tcp port using uri wss://foo:bar@127.0.0.1:33211/: expected info client to return OK but got CONNECTION_FAILED
* failed to connect to    ws port using uri wss://foo:bar@127.0.0.1:39927/: expected info client to return OK but got CONNECTION_FAILED

Slightly different failure, but hopefully the same cause.

[totaam]

Was caused by stray newline characters.
It seems that the http handler occasionally stops parsing before or after the empty newline \r\n that follows the headers, so we now strip it before starting the websocket packet parsing.