use timeouts when sending messages for stream open, close, and reset.

[vyzo]

Closes #51 #48

[vyzo]

test failures are #47

[vyzo]

We might also consider not sending a reset message at all, just swallow the remote error.

[raulk]

Looking at this closer, I think this patches the wrong sites. Calls to Reset() and Close() can still block forever. It seems that patching sendMsg to fallback to a grace period iff the context has no deadline would cover all bases more accurately:

go-mplex/multiplex.go

Lines 150 to 155 in dec60e0

	dl, hasDl := ctx.Deadline()
	if hasDl {
	if err := mp.con.SetWriteDeadline(dl); err != nil {
	return err
	}
	}

[vyzo]

I think this patches the wrong sites.

Not the wrong sites, these sites clearly need to be patched. It's just not all of them.

Calls to Reset() and Close() can still block forever.

We have no mechanism to propagate the error to the user in these cases, and I don't know what the semantics of failing to reset or close because of a timeout should be.
Maybe we should just close the connection when it happens?

[vyzo]

Also patched the Reset call site, but with hard reset semantics.
If it fails to reset within the timeout (1min), it kills the connection entirely.
I don't think we need to patch Close, as it returns the error synchronously.

[vyzo]

actually we probably need a timeout there, and return the error.

[vyzo]

actually we probably need a timeout there, and return the error.

We don't really take action on the error in our code, and at best we would reset the stream.
So I added the timeout and make it kill the connection, hard reset style, if the Close fails.

[vyzo]

summoning @Stebalien @raulk -- this has been thoroughly tested, let's review and get it merged!

issues addressed