Fix Channel Close Behavior

[jaredoconnell]

Changes introduced with this PR

This PR lets the user be responsible for closing signal channel. This proposed design is the "correct" one. Golang specifically does not recommend that receivers close the channel, which is what was happening. And there was no way to reliably ensure that the channel was open on the sending side, leading to race conditions.

This was discovered while working on the engine. There were issues where I sent on a closed channel.

---

By contributing to this repository, I agree to the contribution guidelines.

[dbutenhof]

As long as it gets closed somewhere, that's fine. I'm a little worried that this may be changing the external interface of the SDK (adding a requirement that the client closes the channels when done?), which may suggest a major version and careful documentation? (Although it's unlikely anyone but the engine is using it.)

[jaredoconnell]

As long as it gets closed somewhere, that's fine. I'm a little worried that this may be changing the external interface of the SDK (adding a requirement that the client closes the channels when done?), which may suggest a major version and careful documentation? (Although it's unlikely anyone but the engine is using it.)

Interestingly, it's also perfectly valid to not close it. It's up to the user to determine how they want to use it. They just need to make sure the buffer is large enough that if the other end isn't receiving, it doesn't deadlock itself.