Connection handling issue about lightning-kmp

[romainbsl]

I really thought that we weren't processing old LN messages when (re)starting the Peer with a fresh connection.
I think we all agree that we need the reproduce this in a test case, unit and/or integration, to be sure it will not happen again. Maybe this is where the Peer unit test mechanism will be useful.

I not sure that it that easy to discard some TCP socket message, because we still can receive / process TCP messages before the state machine has processed the Disconnect event. My first thought was to work on the coroutine that handles the TCP workflow, and by cancelling it the TCP should close itself and trigger the Disconnect event.

[t-bast]

@romainbsl @sstone it looks like an issue in connection management, can you investigate? I'm hoping we can fix the connection layer to avoid being in that case, otherwise we'll have to do some nasty work-arounds to ensure our state stays consistent...

[t-bast]

Note that a simple solution could be to discard the contents of the tcp socket once the peer considers the connection closed?
In this specific example it means we would discard the last commit_sig, so when doing our channel_reestablish on the new connection we would tell our peer to retransmit it and everything would work.