iproto: connection could block forever after a CALL request

Starting with 1.9, CALL request which yields releases
the intput buffer in net thread before CALL is complete.
A release trigger is fired when the CALL fiber yields.

The problem is that by default the input socket is not
included into poll() list of the event loop: thanks to an
optimization by @kostja for strict request/response scenario,
the socket is included into poll() list only after the response
is sent to the client. Thus, the following could happen:

* a client sends a long-polling request
* the request yields and maybe never finishes
* the socket is not being read until the long-polling request
  is finished

The patch is to explicitly feed EV_READ event to the event
loop on the client socket whenever we release the input buffer
for a long-polling request.

We may remove iproto_resume() from net_discard_input() along
with this patch since iproto_resume() will be called by
iproto_connection_on_input().