This includes upgrading the logging framework to the V2 framework. This
new framework lets us deprecate the `maxlogfiles` and
`maxlogfilesize` config options.
Move WriteElement[s] to the codec package so that packages other than
clientdb can use it.
For the codec package, we avoid depending on other packages within Pool
so that no circular dependencies develop. This requires us to move some
of the uintXX casting logic in clientdb/codec.go to call sites.
A prior check is now invalidated as the sidecar bucket houses a
sub-bucket that we use to store the set of bid information related to a
sidecar channel.
In this commit, we add a new method that lets us insert a sidecar ticket
as well as a bid in an atomic manner. We'll use this later when offering
this new type of automated ticket.
To make sure we don't just block for forever if another Pool daemon
process is already running, we add a timeout and error out if obtaining
the unique file lock fails after 5 seconds.
A sidecar channel uses different multisig keys than a normal order so we
need to fix the lookup in the batch transaction. While we're at it, we
might as well return the self chan balance and whether it was a sidecar
channel in the leases response.
With this commit we add the optional sidecar ticket to bid orders.
Because the node submitting the bid order doesn't necessarily need to be
the node creating the offer, we just store the ticket as is and don't
require it to be in the database already.
Both the trader offering to buy a sidecar channel for another node as
well as the recipient node will need to store the involved sidecar
tickets in their local databases. We add a simple store interface and
its implementation that will be used in future commits.
To make it way easier to add more data to orders, we add an extra key
in the order's bucket that will contain all future additional data
encoded as a tlv stream.
The PR containing this commit will likely become quite large as is and
therefore we don't want to overload it more by also adding a DB
migration. This can always be done in the future.
We add a new order version that is allowed to submit lease durations
outside of the default/legacy 2016 block duration.
No new fields are added, so nothing changes in the serialization or the
digest. This version only signals that the client is able to process
batch requests with multiple duration buckets.
Because we now only use the batch TX from the local pending batch
snapshot, the redundant information in the pending batch TX key is not
needed anymore.
To be able to fully clean up an old, pending batch snapshot on daemon
startup, we first need to switch to a method that returns the full
snapshot instead of just its ID.
In preparation for loading the full local pending batch snapshot instead
of only the ID when starting the daemon, we add a new function to the
database to retrieve the snapshot.
In this commit, we add a new key within the order bucket that stores
just the node tier for a given order. The current code only _expects_ a
node tier to exist for Bid orders, however things have been designed
such that, we can easily add tier options for Ask orders as well.
Along the way we modify the `orderCallback` to include the node tier
information as its read from a distinct bucket. In the future, we'll
likely want to make this into a struct so the function signature doesn't
ever expand.
In this commit, we replace the existing min/max duration system with a
single field that expresses the expected duration of a lease. Note that
we've left some of the exiting logic in place that select a duration
from a bid in an attempt to make this more of a "soft fork" which will
allow any existing orders to be cleared out as normal before we switch
over.
Once we add multiple durations (this commit assumes a single duration),
we'll need to modify the verification logic to be able to handle
multiple clearing prices for a given batch.
We also want to know whenever we reject a batch either fully or
partially so we also store an event for each involved order in case of a
reject message.
We create and store an event every time an order is involved in a match
making process. We track the three distinct phases a batch goes through
from the trader's point of view so we can visualize this process in the
future.
To make sure the source bucket in updateOrder always is the root order
bucket, we extract the single case were it didn't use to be that way
into its own function called copyOrder and use that for applying the
final batch updates.
We add a couple of order specific events which we use to track the
activity around orders. Some events track the timestamps at which we
persist a change to orders, other events track more volatile occurrences
of the match making process.
