QWebSocket: Stop processing data after a protocol error

RFC 6455 paragraph 7.1.7 states that an endpoint must not continue to
process data from the remote endpoint, including a responding Close
frame, after being instructed to fail the connection. Paragraph 7.1.1
adds that such a close should discard any trailing bytes already
received.

QWebSocketDataProcessor::process() returned true when encountering an
error, the same value it returns for a successfully processed frame, so
QWebSocketPrivate::processData() kept iterating. Frames following the
violation were still delivered, and the bytes a rejected frame announced
as its payload were parsed as framing, so a peer could have a message
delivered that it never sent as a valid frame.

Mark the connection as failed instead and parse nothing further for it
until clear(), which QWebSocketPrivate::open() already calls per
connection.

There is also nothing left to wait for once a connection has failed, so
close the transport straight away instead of creating the close timer.
The timer stays for an application-initiated close, which still waits
for the peer's Close frame.

Add tests to tst_DataProcessor, covering every error the data processor
reports.

Update tst_DataProcessor::frameTooSmall(), because it was using the same
processor instance without resetting it.

Also fix the test's RSV2 constant.

Behaviour change: no frame or message signals after errorEncountered(),
and disconnected() arrives up to three seconds earlier on an error.

Pick-to: 6.12 6.12.0 6.11.3 6.8
Fixes: QTBUG-150271
Change-Id: I5ceb6d1fb37e6cd6dbbacb4e6f31aba864ac1396
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>