Eliminate False-Alarm Logs #795

Occasionally, the browser and the server decide to close a particular stream at the same moment. When that happens, the ProxyServer (originating Node) will send a zero-byte last_data = true CORES package to the exit Node telling it to close the connection, and will also remove the stream's stream key from its memory. But on the other end, the dropped connection from the server will produce a zero-byte last_data = true CORES package back to the originating Node. Each end is notifying the other of the demise of the connection without knowing that the other end is already aware and in the process of notification itself.

When this happens, the notification from the exit Node arrives back at the originating Node with its stream key, and the originating Node tries to look that stream key up in its memory, and fails--because it just removed that stream key milliseconds ago. So we get this log:

2024-05-16 09:35:30.617 Thd20: WARN: ProxyServer: Discarding 0-byte packet 1 from an unrecognized stream key: dnASbKMjBfQZv9d86hkLpfhCQvU; can't send response back to client

There's no stream from the originating Node back to the browser, says this log, so I can't process this CORES package.

That's perfectly okay: there's no stream because the browser closed it. This condition should raise no eyebrows.

Task:

1. In the ProxyServer, when we're about to write the log above, examine the CORES package whose reception put us in that situation, and see whether it's a last_data = true log. If it is, either don't write the log at all, or demote it to an INFO or DEBUG log.
2. Examine the ProxyClient and find the code for the parallel situation there. If we're writing a similar log on the exit-Node side, modify the functionality there the same way.