Add The ability to manually accept/reject each channel

[TheBlueMatt]

Following up from #1135, we should have the ability in config to enable generating an event prior to accepting a channel, and then have the user make a callback to accept or reject it. In the future, we'll want to use the callback to indicate if we're willing to accept the channel with 0conf, presumably due to some out-of-band negotiation that has occurred with the initiator.

[ViktorTigerstrom]

I'd like to be assigned to this issue if it's possible and this isn't already being worked on.

Do I understand the issue correctly that I’d solve it by implementing the following parts?

A new config flag shall be created which indicates that a manual acceptance or rejection of new inbound channels is required. The flag will default to false.

We would also need to create a new type of Event that is pushed to the pending_events in the internal_open_channel function of the ChannelManager if the new config flag is set to true. The parameters of the Event should detail the information about the new requested channel.

We'd need to create a callback that indicates whether the user has accepted or rejected the request for the new channel. If the channel is accepted a SendAcceptChannel msg_event is pushed, and if rejected an Err of type MsgHandleErrInternal::send_err_msg_no_close is returned.

[TheBlueMatt]

Sure, feel free to take it on! What you described is all basically spot on, just make sure no SendAcceptChannel event is generated prior to the callback being called if the config option is set.

[ViktorTigerstrom]

Perfect! Thanks for the input, I'll make sure of that. I’ll comment again if any more questions arise.

[ViktorTigerstrom]

I just made a pull request with the feature implemented. I'm however not completely satisfied with my implementation, so please provide feedback if you can think of a better solution :).

In the description of this issue, it's specified that the response to a channel open request should be in the form of a callback. I've had to solve this by creating a public function respond_to_open_channel_request in the ChannelManager, which is to be called to accept or reject the channel open request. A request to open a channel is indicated to the user through the OpenChannelRequest event I've created. An issue with this solution is that some information which is not really needed for the user to determine whether they should accept the channel request or not is passed with the OpenChannelRequest. This information is only passed as it's required when the user later want's to respond to the request by calling the respond_to_open_channel_request function.

A cleaner solution could perhaps be seen creating a proper callback which passed with the OpenChannelRequest event, which is then to be called to respond to request, and letting the callback encapsulate the information required for the response. However if we were to create this callback and pass it with the OpenChannelRequest event, it would need to be a closure and not a function pointer as we'd need variables outside the scope of the function. In order to use a closure we would need to make the Event enum generic as it implements the Clone and Debug traits, which is not really an option. I therefore got stuck when experimenting with this path, and opted to implement the respond_to_open_channel_request function instead.

I hope this solution is ok, but regardless all feedback is greatly appreciated!
Let me also know if you want me to create an implementation of the event and feature for the ldk-sample repo, or perhaps some tests.

[TheBlueMatt]

Thanks! Let's continue discussion on the PR.

[TheBlueMatt]

Done in #1281.