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.
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.
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.
