disable some code that only makes sense when USE_TUNNEL is defined
in client and server channel security level setting.

This one mistakenly had a GPL header rather then an LGPL header.

drawable_count was becoming negative. It tracks the number of
items in the worker->current_list ring. It was decremented correctly,
but incremented only in several cases. The cases it wasn't incremented
where:
 red_current_add_equal found an equivalent drawable
by moving the increment to where the item is added to current_list, in
__current_add_drawable, the accounting remains correct.

This has no affect other then correct accounting, as drawable_count isn't
used for anything.

We are keeping track of tokens for sending agent data to the client, but
the client send an initial value of ~0, and never gives us new send tokens
so this is all rather useless -> remove it.

Note that it is kept in the migration data struct for compatibility reasons.

read_from_vdi_port(), called from vdagent_char_device_wakeup() may
fail to consume all data because no buffers are available in the
read_bufs ring. When this happens we would fail to ever read more data
from the agent on the guest as the port is throttled and stays throttled
until we've consumed all data from the current buffer.

This patch re-enables the call to read_from_vdi_port() from
vdi_read_buf_release(), so that we will try the read again when space
becomes available in the read_bufs ring.

Together with another nasty hack in the linux guest virtio_console
driver, where it waits for a write to be acked by the host before
continuing with the next one, this can lead to a linux guest
getting stuck / hang (until the write is read by the spice-server
which never happens becaus of the above issues).

Note that even with this patch, the guest will still gets stuck due to
a bug in watch_update_mask in spice-core in qemu, which causes writing
to the client to never resume once it blocked. A patch for this has been
submitted to qemu.

read_from_vdi_port() MUST always be called in a while loop until it returns 0.

This is needed because it can cause new data available events and its
recursion protection causes those to get lost. Calling it until it returns 0
ensures that all data has been consumed.

Example scenario where we can fail to read the available data otherwise:
- server/reds.c: vdagent_char_device_wakeup get called
  by hw/spice-vmc.c because data has arrived from the guest,
- hw/spice-vmc.c: vmc_read get calls
- If the vmc_read call depletes the current buffer it calls
  virtio_serial_throttle_port(&svc->port, false)
- This causes vmc_have_data to get called, which if in the
  mean time another buffer has arrived causes
  vdagent_char_device_wakeup to gets called again
  (so recursively)
- vdagent_char_device_wakeup is protected against recursive
  calling and ignores the second call (a nasty hack)
- if no other data arrives, the arrived data will not get read