This commit adds a batch insert to the interface. This greatly reduces
the time the migration will take. It is not implemented for the boltdb, as
we will not be supporting migrating to the boltdb.
This commit adds a new struct to hold all HTLC keys and refactors the
SwapContract which is used by both loopin and loopout swaps to use this
new struct. The newly added internal keys will for now hold the script
keys to keep everything equivalent but are already stored and read back
if the protocol version is set to MuSig2.
This commit adds a new bucket to save liquidity parameters. We've
skipped the serialization and deserialization implementations here and
leave them to be handled by the liquidity package.
To make sure we don't just block for forever if another Loop daemon
process is already running, we add a timeout and error out if obtaining
the unique file lock fails after 5 seconds.
This commit adds the protocol version to each stored swap. This will be
used to ensure that when swaps are resumed after a restart, they're
correctly handled given any breaking protocol changes.
To allow users to specify differing confirmation targets, we store the
swap conf target per-swap. This makes us restart safe, so we do not
forget confirmation values for swaps that are in flight when we restart.
This commits adds an optional label to our swaps, and writes it to
disk under a separate key in our swap bucket. This approach is chosen
rather than an on-the-fly addition to our existing swap contract field
so that we do not need to deal with EOF checking in the future. To allow
creation of unique internal labels, we add a reserved prefix which can
be used by the daemon to set labels that are distinct from client set
ones.
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.
