This avoids us trying to restore the original resolution when we're fullscreen
and an X error happens. As restoring fullscreen is a bad idea then as this
involves making more X calls, which can get us stuck (in side an XLockDisplay
call for example).

When starting spicec with --controller, SPICE_XPI_SOCKET environment
variable must be defined so spicec and the controller can be connected.

spice-server tries to use the migration information without checking
whenever this is available in the first place ...

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

uses VSC_Error with code==VSC_SUCCESS instead. This means that the VSC_Error
message is overloaded. Instead of the other option of adding a message id,
since the connection is TCP so no messages may be dropped or reordered, by
having each message followed by a response there is no ambiguity. Still
this commit adds a queue for messages that we only have one of which outstanding
at a time, i.e. send, wait for response, send the next, etc. This further
simplifies the logic, while not adding much overhead since only when spicec
starts up it has a situation where it needs to send two events (ReaderAdd
and ATR for Card Insert).

The device already sends one. There are actually two connections going
on:
 server to client - this is the smartcard channel, it reuses the VSC protocol.
 server to device - this is an internal connection using VSC too.

We generally just passthrough all messages from the client to the device,
and from the device to the client. We only rewrite the reader_id because
the device knows about a single id (it is actually a card id), and we
may manage more then one in the future.

Bottom line is that there was an extra VSC_Error message reaching the client.