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 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.
This commit aims to address a current gap within the system where trader
account states can become desynchronized if they participated in a batch
and they never received a Finalize message from the auctioneer.
From now on, if an account spend arrives while a trader has a pending
batch, then we assume they weren't able to receive its Finalize message,
and use the spend as an indication that the batch has been finalized.
This works because if a trader signs for a batch and disconnects, the
batch should have already been persisted, and if the batch was actually
finalized (i.e., broadcast without any changes), then the account should
have been spent.
If trader A provides a signature for a batch, disconnects, and trader B,
who is also in the auction, bails, then the auctioneer will re-attempt
matchmaking. If trader A hasn't reconnected by and a successful batch is
made without them, then the updates would need to be rolled back.
Previously, since we would overwrite the main account and order state,
we'd lack information in order to do so. By staging the update under a
distinct bucket, we can now do so properly by simply removing the state
within it.
This commits serves as preparatory work for committing a pending batch
before providing signatures to the auctioneer. This is achieved by first
storing the batch as pending upon receiving a new batch and marking it
as complete upon receiving a finalize message.
