Add blocking functionality to channels

[notgull]

As per discussion in smol-rs/async-lock#25, I have added send_blocking and recv_blocking methods to the Sender and Receiver structures, respectively. In order to reduce code duplication, I implemented this by parameterizing the logic found in the Send and Recv futures using a trait that either polls the EventListener or calls wait on it.

Various things I left up in the air:

• I added private wait() methods on Send and Recv that use the blocking strategy to poll the future to completion. Should these be public?
• Recv currently implements Stream. It could also implement Iterator using a similar strategy to how I implemented blocking for the main methods. I decided against it, since StreamExt and Iterator share many method names which could be confused. Is there an idiomatic way of going about this?
• Do I need more tests? Since I piggyback off of the previous logic I didn't think so, but I'm not sure what the general policy is.

Closes #21

[taiki-e]

• I added private wait() methods on Send and Recv that use the blocking strategy to poll the future to completion. Should these be public?

I would prefer not to provide public wait methods. see also smol-rs/async-task#16 (comment).

• Recv currently implements Stream. It could also implement Iterator using a similar strategy to how I implemented blocking for the main methods. I decided against it, since StreamExt and Iterator share many method names which could be confused. Is there an idiomatic way of going about this?

I agree with your decision here not to implement Iterator.

FYI, one of the ways to handle such cases is to provides a wrapper type like BlockingReceiver that implements Iterator and a method to convert it from Receiver explicitly. That said, I don't see the need to provide it until someone actually needs it.

[notgull]

Are there any blockers (no pun intended) for merging this?

[taiki-e]

I feel that the trait-based solution is a bit overkill, but I'm not sure if there are other good alternatives.

So I think this is ready to merge, aside from a nit.

[notgull]

The nit is fixed now, want me to squash it?

[taiki-e]

Thanks!

[taiki-e]

Published in v1.7.0.