properly handle closing streams before they are ACKed

[whyrusleeping]

Should address bug #26. The issue occurs when opening unidirectional streams then closing them quickly before the other side can ACK the open.

[whyrusleeping]

After further testing I can still reproduce the bug (though it requires far more effort) in ipfs. In the small reproduction program posted in the tracking issue I cannot get a repro.

EDIT:
I think that the issue i'm seeing here is things getting very backed up (as is expected, thats what we're testing) and causing the keepalive to fail and close down the session. I'm not sure what I think of this behaviour...

EDIT2:
Got a repro outside of the ipfs codebase: https://gist.github.com/whyrusleeping/afa2b499fb9f7c73ff254f0df2501e23

It looks like the client gets into a bad state after some number of streams, while the server side continues along fine

[whyrusleeping]

Alright, got it figured out properly. Ready for review

[whyrusleeping]

one potential issue is that this can still lock up if one side doesnt have the fix. (since they won't ACK correctly). This could be addressed either by requiring everyone to use the correct version, or maybe by adding a timeout to that select case in session.go:149

[slackpad]

Hi @whyrusleeping thanks for the PR and sorry for the delay - finally had a little time to go through this in some detail. I think there should be a way to do this completely on the sender side without relying on the other party sending an ACK to clear the semaphore. I'll work up a change based on your PR and post it here shortly.

[whyrusleeping]

@slackpad thanks for getting that in. Not relying on the other side to be correct is definitely a better solution.