With this commit we address two issues with the connection to lnd:
First, we didn't specify the required version of lnd even though we used
features of 0.11.0. This is fixed by pinning the version to 0.11.0
explicitly and specifying the subservers that are required to be active.
Second, we didn't wait for lnd to be synced to its chain backend. We use
the new functionality in the lndclient repo that does exactly this.
In this commit, we add some new logic to reconcile our local order state
with what the auctioneer has on start up. However, we'll only update our
local order if the auctioneer shows the order as being cancelled. For
all other cases, we should reconcile that difference if we have a
pending batch that was confirmed while we were offline, or confirmed
after we sent our signature. In this case, we'll log the order nonce
with a warning log-level so users can track down any possible issues.
As a preparation to be able to interact with the LSAT store on the RPC
level, we need to hold a reference to it in the server. So far we also
don't pass the client DB to the RPC server but instead access it through
the server struct. We do the same for the LSAT store.
In the integration tests, we start the client manually as part of the
set up process. When the trader is run in a standalone manner, we still
need to ensure the client is started, otherwise the auth handshake can't
take place.
In this commit, we add the missing logic to register for funding shims
when we're the taker of an executed order, and also to establish new
channels after we send OrderMatchAccept when we're the maker of an
executed order.
As a temporary work around, we'll also add a full lnd client, as we'll
need to do things like connect to peers, register for funding shims, and
also open channels. In the future we'll catch up lndclient to add these
new methods so we can use mocks in our unit tests.
This commit aims to address another gap within the system to ensure
trader pending batch states are as accurate as possible. In a previous
commit, we addressed the case of a trader signing for a batch,
disconnecting and not receiving a Finalize message, and seeing a spend
for an account.
Here, we're interested in determining whether a batch a trader signed
for is actually still relevant to the trader. Since any trader can bail
from a batch, the batch may need to be re-done by the auctioneer, and if
a trader that previously signed for a previous version of the batch
remains disconnected, then they won't be aware of said new batch. At
this point, the trader has a lingering pending batch that's no longer
irrelevant, so we remove it. This logic is tied to the connection
establishment between the trader and auctioneer to ensure we handle the
disconnection and crash case of a trader after signing for a batch.
