This commit fixes the generation of the htlc address. This bug didn't
affect the swap execution, because the htlc address is only used for
display to the user/caller.
In this commit, we modify all sub-servers as well as the main lnd gRPC
service to use a macaroon per call rather than a connection level
macaroon. The old approach would result in us using the same macaroon
for the entire connection, while this new approach allows us to use
multiple macaroons with a single connection.
We move to this new approach as it doesn't require users to delete their
admin macaroon before being able to use Loop. It also preps us for a
future where there is no admin macaroon, and we instead need to use a
set of macaroons to accomplish our tasks.
In this commit, we modify the `NewLndServices` method to accept the
directory where macaroons are stored, rather than the path for the admin
macaroon. This is a prep to moving towards a multi-macaroon system, as
the `macaroonPouch` will handle storing the various macaroons.
In this commit, we add a new struct, the `macaroonPouch`. This struct
bundles all the macaroons we need for each sub-server. Along the way, we
also export the set of default* paths for lnd, and add a new set of
variables that store the default file names of each of the macaroons for
each sub-server.
The `WithMacaroonAuth` method on the `serializedMacaroon` type will
allow us to attach a macaroon for each call rather than attaching it at
the connection level. This slight change will allow us to use multiple
macaroons over a single RPC connection, rather than a single global
macaroon.
Allow user to specify that htlc will be published by an external source.
In that case no internal htlc tx will be published.
To facilitate sending to the htlc address, the swap initiation response
is extended with that address.
This commit adds the required code to persist loop in swaps. It also
introduces the file loop.go to which shared code is moved.
Sharing of contract serialization/deserialization code has been
reverted. The prepay fields do not apply to loop in, but were part of
the shared contract struct. Without also adding a migration, it wouldn't
be possible to keep the shared code.
In general it is probably more flexible to keep the contract
serialization code separated between in and out swaps.
