Work around unhelpful GTK event ordering.

If the SSH socket is readable, GTK will preferentially give us a
callback to read from it rather than calling its idle functions. That
means the ssh->in_raw bufchain can just keep accumulating data, and
the callback that gets the BPP to take data back off that bufchain
will never be called at all.

The solution is to use sk_set_frozen after a certain point, to stop
reading further data from the socket (and, more importantly, disable
GTK's I/O callback for that fd) until we've had a chance to process
some backlog, and then unfreeze the socket again afterwards.

Annoyingly, that means adding a _second_ 'frozen' flag to Ssh, because
the one we already had has exactly the wrong semantics - it prevents
us from _processing_ our backlog, which is the last thing we want if
the entire problem is that we need that backlog to get smaller! So now
there are two frozen flags, and a big comment explaining the
difference.

sshserver.c

@@ -201,6 +201,13 @@ void ssh_throttle_conn(Ssh *ssh, int adjust)
     }
 }
 
+void ssh_conn_processed_data(Ssh *ssh)
+{
+    /* FIXME: we could add the same check_frozen_state system as we
+     * have in ssh.c, but because that was originally added to work
+     * around a peculiarity of the GUI event loop, I haven't yet. */
+}
+
 static const PlugVtable ssh_server_plugvt = {
     server_socket_log,
     server_closing,