feat: channels for dlc messages

[bennyhodl]

Instead of polling for messages for MessageHandler consumers. You can subscribe to receive the messages over the channel.

This PR is to start a conversation of what we would like to implement.

• Tokio broadcast channel allows multiple consumers and works similar to how rust nostr handles relay notifications.
• Standard lib mpscchannel. Only allows one consumer, we might want to opt for a channel crate that is synchronous and allows multiple consumers

[bennyhodl]

Added a crossbeam channel for better performance and thread safety. Sync channel has to be wrapped in Arc<Mutex<Receiver>> and does not allow multiple consumers.

I think we can have an async-channel and sync-channel feature for each.

[Tibo-lg]

I think there are many ways to implement a MessageHandler. For some polling will be better, for some event based will be better, and it is possible to convert one to the other as well. The implementation in the crate is there mainly to be used by those who don't have specific needs, and I don't think there is a strong need to change it from polling to a pub/sub system, especially if it means pulling in more dependencies which I try to avoid as much as possible for the core crates. If someone has that need, they can go ahead and create their own MessageHandler. If you think that some things could be improved to make it easier to implement custom handlers, I think that would be valuable.

[bennyhodl]

I am not proposing to get rid of the polling. Default feature is the polling and a feature for channels (which the dependency would only be used if feature is on).

[Tibo-lg]

Sorry for the late reply. I understand you want to have that feature gated, but even then it means having dependencies to update and more code to maintain, for something that is not core to the functionality of the library. Again I think it would be very valuable to have better support to develop custom MessageHandler, but I don't think adding new features or functionalities is worth the additional maintenance work. I know several users of the library have created custom MessageHandler to fit their need, and there didn't seem to have been any issue.