fix: don't eat the next value when a streaming rpc call ends as expected

I was just wiring up a MsgPack codec that doesn't support decoding into nil values (I didn't know that the gob decoder allowed you to discard values in that way -- interesting!) and I noticed that my decoder was always returning an error after the last stream response.  In any case, I think that it's a bug to discard the next value on the connection after the last stream response.  Cheers!