red-worker: Start processing commands as soon as possible

When the worker is started it could take a while to start processing
commands.
The reason is that the dispatcher handler is called after the worker
so GLib will receive a FALSE answer to both prepare and check
callbacks of the RedWorkerSource causing GLib to wait till another
event is received.
This is a regression since the introduction of GLib event loop, before
the command processing was always attempted after any events.
Commands (from QXL interface for cursor and display) are processed
during the RedWorkerSource dispatch so if they are not processed just
when the VM is started they will be processed on next event which
could be from dispatcher (main thread requests), from existing
connections or from pending timers. However in the case there are no
clients connected and no other requests from main thread the worker
thread won't process them.
Setting the event_timeout to 0 cause the prepare callback to return
TRUE so GLib will dispatch the RedWorkerSource.
This was discovered attempting to use the tests in server/tests
directory to reproduce a leak in RedWorker.

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>

server/red-worker.c

@@ -640,6 +640,7 @@ static void handle_dev_start(void *opaque, void *payload)
         display_channel_wait_for_migrate_data(worker->display_channel);
     }
     worker->running = TRUE;
+    worker->event_timeout = 0;
     guest_set_client_capabilities(worker);
 }