In this commit, we fix a slight bug in the existing implantation that
would cause no channel recovery if the recovering node was already
connected to their channel peer. As we need the link to be known at the
time of connection, if we're already connected, then the chan sync
message won't be sent again. By first disconnecting an existing peer, we
ensure that during the next connection (after the recovered channel is
added to the database), then the regular chan sync message exchange will
take place as expected. # Please enter the commit message for your
changes.
In this commit, we fix a bug in the existing logic for ConnectPeer that
would cause an SCB restore to fail if we were already connected to the
peer. To fix this, we now instead will just return with a success if
we're already connected to the peer.
In this commit, we convert the server's Start/Stop methods to use the
sync.Once. We do this in order to fix concurrency issues that would
allow certain queries to be sent to the server before it has actually
fully start up. Before this commit, we would set started to 1 at the
very top of the method, allowing certain queries to pass before the rest
of the daemon was had started up.
In order to fix this issue, we've converted the server to using a
sync.Once, and two new atomic variables for clients to query to see if
the server has fully started up, or is in the process of stopping.
In this commit, we move the location where we restore the channel status
to within the `RestoreChannelShells` method itself. Before this commit,
we attempted to use `ApplyChanStatus` which creates a DB transaction and
relies on a fully populated channel state, which in the restoration
case, we don't yet have.
The `openChannelShell` method now includes the new config information
within the open channel shells. Additionally, we now properly re-derive
all keys from our local chan config so they're useable immediately in
the channel state machine.
We extend the `chanDBRestorer.RestoreChansFromSingles` method to also
add the new channels to the chain arbitrator once they've been restored
on disk. We do this in order to ensure that we catch the channel closure
on chain once the DLP protocol beings.
