Pierre-Marie Padiou bfd25fa021 Atomically switch to new connection (#1419) ... When a new connection happens while already connected, the `Peer` will switch to the new connection. In the current implementation, upon receiving a `ConnectionReady`, the `Peer` will kill the current connection, then sends back the `ConnectionReady` message to itself. In the meantime, the `PeerConnection` will happily forward any incoming messages to the `Peer`. This opens up to a race in the `Peer`'s mailbox between the `ConnectionReady` message, and any incoming messages from the new connection. If the latter win, they will get dropped because the `Peer` is in state `DISCONNECTED`. Typically those are `ChannelReestablish` messages and channels will get stuck in state `SYNCING`. This PR make the `Peer` atomically switch to the new connection, without going back to the `DISCONNECTED` state. As a result, we now have a `CONNECTED`->`CONNECTED` transition.		2020-05-15 14:40:06 +02:00
..
src	Atomically switch to new connection (#1419)	2020-05-15 14:40:06 +02:00
eclair-cli	Typed amounts (#1088)	2019-08-07 17:37:38 +02:00
pom.xml	Skip executing some plugins when skipping tests (#1418)	2020-05-13 15:19:48 +02:00