Revert "server/red_channel: red_channel_event: push on blocked"

This reverts commit 5062433d8af45822371b6487a8d7baea23071d18.

red_channel_receive() can call red_channel_destroy() which frees
channel.

The condition bellow is then checked, which can access a freed
channel:

if (event & SPICE_WATCH_EVENT_WRITE || channel->send_data.blocked)

Reverting this commit solves the issue without any apparent
bugs/drawbacks, which kind of clears out the weird TODO.

handle_dev_input: cursor connect
==11826== Invalid read of size 4
==11826==    at 0x4C6F83C: red_channel_event (red_channel.c:535)
==11826==    by 0x41CB8C: main_loop_wait (vl.c:1365)
==11826==    by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589)
==11826==    by 0x41FE9A: main (vl.c:1411)
==11826==  Address 0x31fb00f0 is 96 bytes inside a block of size 28,648 free'd
==11826==    at 0x4A05372: free (vg_replace_malloc.c:366)
==11826==    by 0x4C6F536: red_channel_destroy (red_channel.c:453)
==11826==    by 0x4C52B5D: inputs_channel_on_incoming_error (inputs_channel.c:449)
==11826==    by 0x4C6ED0E: red_channel_peer_on_incoming_error (red_channel.c:215)
==11826==    by 0x4C6E731: red_peer_handle_incoming (red_channel.c:87)
==11826==    by 0x4C6EA55: red_channel_receive (red_channel.c:154)
==11826==    by 0x4C6F82D: red_channel_event (red_channel.c:530)
==11826==    by 0x41CB8C: main_loop_wait (vl.c:1365)
==11826==    by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589)
==11826==    by 0x41FE9A: main (vl.c:1411)
==11826==

https://bugs.freedesktop.org/show_bug.cgi?id=34971

0 files changed, 0 insertions, 0 deletions