Process all pending WS messages

[kziemianek]

Keep on processing ws messages even if all data from tls stream was read.

Before we were reading all data from tls stream while processing only single message from websocket connection. If there was no data in stream then connection was closed, even if there were more than one message to be processed from ws connection.

Problematic flow:

1. client sends 1000 messages very fast
2. mio event raised
3. all data read from tls stream
4. only one ws message processed
5. mio event raised
6. no data in tls stream (all was read in previous iteration)
7. connection closed (leaving 999 messages not processed)

[linear]

P-907 Only one ws message read per mio event

[BillyWooo]

Will we still have a "final solution" ? Or we stop here for the moment?

[Kailai-Wang]

What if we simply continue as long as tls_session.read_tls() returns Ok without checking the actual read length? process_new_packets shall be called in any case, and I assume it will be "processed" even if 0 bytes were read.

We follow it by ws data frame processing as long as mio event is triggered, something like:

    for event in &events {
        if event.readiness().is_readable() {
            // TLS layer tries to read and decrypt data.
            let tls_read_result = tls_session.read_tls(&mut tcp_stream);
            
            if tls_read_result.is_ok() {
                tls_session.process_new_packets().unwrap();
                
                // WebSocket layer reads from the decrypted TLS buffer.
                if let Ok(Some(message)) = ws_stream.read_message() {
                    // Process the WebSocket message
                    println!("Received message: {:?}", message);
                }
            }
        }
    }

[kziemianek]

@Kailai-Wang we can do that, i've changed the code.

That was my initial fix but:

1. I was unsure about root cause (why there are more mio events but not data in tls stream)
2. PollOpt::Level is deprecated so if we decide to bump mio version in future we will need to change it anyway

[BillyWooo]

@Kailai-Wang we can do that, i've changed the code.

That was my initial fix but:

1. I was unsure about root cause (why there are more mio events but not data in tls stream)
2. PollOpt::Level is deprecated so if we decide to bump mio version in future we will need to change it anyway

As far as I can recall, there was problem with "more mio events but not data" vs "more data but no mio event". I can't recall the detail. That's the reason we had such fix in #2852, right ?

[kziemianek]

@Kailai-Wang we can do that, i've changed the code.
That was my initial fix but:

1. I was unsure about root cause (why there are more mio events but not data in tls stream)
2. PollOpt::Level is deprecated so if we decide to bump mio version in future we will need to change it anyway

As far as I can recall, there was problem with "more mio events but not data" vs "more data but no mio event". I can't recall the detail. That's the reason we had such fix in #2852, right ?

We claimed at that time that mio events were missing.
If we expect 1000 events, but connection is closed after processing 4 of them, then connection will be deregistered and remianing will never be emited.