configure.ac comment typo nit
TIOCOUTQ -> SIOCOUTQ and portability ifdefs

The ioctl on sockets is actually named SIOCOUTQ though its value
is identical to TIOCOUTQ which is for terminals.
SIOCOUTQ is linux specific so we add a header check and ifdef based
on the presence of the header
This prevents bogus ioctls on non-Linux platforms
server/red_worker.c: remove unused pipe_item_remove
server/red_channel: fix unused variable

unused variable 'so_unsent_size' [-Werror=unused-variable]
red_channel: prevent adding and pushing pipe items after a channel_client has diconnected

Fixes: leaks of pipe items & "red_client_destroy: assertion `rcc->send_data.size == 0'"

red_channel_disconnect clears the pipe. It is called only once. After,
it was called, not items should be added to the pipe.

An example of when this assert can occur:
on_new_cursor_channel (red_worker.c), pushes 2 pipe items.
When it pushes the first pipe item, if the client has disconnected,
it can hit a socket error, and then, red_channel_client_disconnect is called.
The second call to adding a pipe item, will add the item to
the pipe. red_channel_client_pipe_add_type also calls
red_channel_client_push, which will update the send_data.size.
Then, the push will also hit a socket error, but red_channel_client_disconnect
won't clear the pending pipe item again, since it was already called.
When red_client_destory is called, we hit assertion `rcc->send_data.size
== 0'.
Note that if a pipe item is added to the pipe after
red_channel_client_disconnect was called, but without pushing it,
we should hit "spice_assert(rcc->pipe_size == 0)".
red_channel: add ref count to RedClient
main_dispatcher: add ref count protection to RedClient instances
decouple disconnection of the main channel from client destruction

Fixes rhbz#918169

Some channels make direct calls to reds/main_channel routines. If
these routines try to read/write to the socket, and they get socket
error, main_channel_client_on_disconnect is called, and triggers
red_client_destroy. In order to prevent accessing expired references
to RedClient, RedChannelClient, or other objects (inside the original call, after
red_client_destroy has been called) I made the call to
red_client_destroy asynchronous with respect to main_channel_client_on_disconnect.
I added MAIN_DISPATCHER_CLIENT_DISCONNECT to main_dispatcher.
main_channel_client_on_disconnect pushes this msg to the dispatcher,
instead of calling directly to reds_client_disconnect.

The patch uses RedClient ref-count in order to handle a case where
reds_client_disconnect is called directly (e.g., when a new client connects while
another one is connected), while there is already CLIENT_DISCONNECT msg
pending in the main_dispatcher.

Examples:
(1) snd_worker.c

    snd_disconnect_channel()
        channel->cleanup() //snd_playback_cleanup
            reds_enable_mm_timer()
                .
                .
                main_channel_push_multi_media_time()...socket_error
                    .
                    .
                    red_client_destory()
                        .
                        .
                        snd_disconnect_channel()
                            channel->cleanup()
                                celt051_encoder_destroy()
            celt051_encoder_destory() // double release

Note that this bug could have been solved by changing the order of
calls: e.g., channel->stream = NULL before calling cleanup, and
some other changes + reference counting. However, I found other
places in the code with similar problems, and I looked for a general
solution, at least till we redesign red_channel to handle reference
counting more consistently.

(2) inputs_channel.c

    inputs_connect()
        main_channel_client_push_notify()...socket_error
                .
                .
            red_client_destory()
                .
                .
        red_channel_client_create() // refers to client which is already destroyed

(3) reds.c

    reds_handle_main_link()
       main_channel_push_init() ...socket error
                .
                .
            red_client_destory()
                .
                .
       main_channel_client_start_net_test(mcc) // refers to mcc which is already destroyed

    This can explain the assert in rhbz#964136, comment #1 (but not the hang that occurred before).
reds: s/red_client_disconnect/red_channel_client_shutdown inside callbacks

When we want to disconnect the main channel from a callback, it is
safer to use red_channel_client_shutdown, instead of directly
destroying the client. It is also more consistent with how other
channels treat errors.
red_channel_client_shutdown will trigger socket error in the main channel.
Then, main_channel_client_on_disconnect will be called,
and eventually, main_dispatcher_client_disconnect.

I didn't replace calls to reds_disconnect/reds_client_disconnect in
places where those calls were safe && that might need immediate client
disconnection.
snd_worker: fix memory leak of PlaybackChannel

When the sequence of calls bellow occurs, the PlaybackChannel
is not released (snd_channel_put is not called for the
samples that refer to the channel).

    spice_server_playback_get_buffer
    snd_channel_disconnect
    spice_server_playback_put_samples
snd_worker/snd_disconnect_channel: don't call snd_channel_put if the channel has already been disconnected

The snd channels has one reference as long as their socket is active.
The playback channel has an additional reference for each frame that is
currently filled by the sound device.
Once the channel is disconnected (the socket has been freed and the
first reference is released) snd_disconnect_channel shouldn't release
a reference again.
log: improve debug information related to client disconnection