Don't check StreamingCallSink is alive at close

[illicitonion]

There is nothing in place which guarantees that sending the last
message on the Sink, and closing the Sink, happen atomically.

There is currently a race condition where if the server responds
incredibly quickly, its response may be received between the last
streaming message being sent, and close being called.

It isn't obvious to me what value this check_alive call is bringing; if
there is one, we should try to guarantee its success by either:

1. Implementing a custom send_all implementation such that the last
   send and close are called atomically, getting rid of the window
   where the race can be lost.
2. Establishing a happens-before relationship between
   StreamingCallSink.close and whatever code receives the server
   response (I think Call.start_recv_message?). I think this would
   either need a pretty coarse-grained lock, or a pretty complex
   restructuring of code.

But as the check doesn't appear to provide any useful guarantees (and
indeed mostly appears to make losing this race condition problematic),
I figured I'd try just removing it...

[BusyJay]

Implementing a custom send_all implementation such that the last
send and close are called atomically, getting rid of the window
where the race can be lost.

SendAll itself will close the sink after sending and flushing the last messages in futures 0.1.x.

...a race condition where if the server responds
incredibly quickly, its response may be received between the last
streaming message being sent, and close being called.

This should be an expected behavior. Sink::close only half close the connection, the other peer can still send any messages freely. Although server is also free to reject receiving any further messages too.

I don't think I understand you completely. It would be helpful if you can explain more details about your problem.

[illicitonion]

My assumption is that once the server has sent a message, further sends from the client cease to be allowed.

What I believe we're seeing is that the server is responding so quickly that the receiving half of the channel is closed before we start trying to close the sending half, and so we get an RpcFinished error when we try to close the sending half.

(I can reproduce this semi-deterministically - about 20% of attempts with the right server behaviour set up on a localhost server, and can deterministically not reproduce it after this PR is applied)

[BusyJay]

Can you add a test case for it?