Fix panics in the mtcp-client

[CryptoCopter]

If the write to reportChan is deferred, and reportChang has already been
closed, then the resulting panic won't be recovered by the deferred
recover-function.

[oxzi]

Good catch, thanks a lot!

However, after applying your suggest changes, an error will not be sent for recovered panics. But especially those errors might be very important.
Thus, I would suggest some kind of multiple stacked defers.

1. defer client.mutex.Unlock(), as before
2. recover and assign errors to err
3. if err != nil {client.reportChan <- cla.NewConvergencePeerDisappeared(client, client.GetPeerEndpointID()) }
4. another recover to catch panics due to an already closed channel.

Due to its stack nature, the defers needs to be applied in reverse.
I sketched this one here: https://play.golang.org/p/JWkgNRg84s7

Of course, this might not be the most beautiful solution but should cover all possibilities.

[CryptoCopter]

come to think of it, I believe that I originally included the recoveronly because of the occasional panics due to sending a message to an already closed reportChan - so so I believe we only need three layers:

1. client.mutex.Unlock()
2. if err != nil {client.reportChan <- cla.NewConvergencePeerDisappeared(client, client.GetPeerEndpointID()) }
3. recover in case reportChan is already closed

[oxzi]

Let's start with some history. The first deferred recover was introduced in early 2019 by fa14812 to mitigate a panic within go-codec, I guess. However, in the meantime the whole functional body of this method was changed completely.

I think you are totally right that one recover is enough.
The point about two recovers was that a panic from within the method's body could still be sent into the channel. However, I don't see any "panicable" code there anymore.

LGTM, thanks again!