If we detect we have a pending batch in the local database that was
replaced by a different transaction, we try to clean up funding shims
and pending channels on startup as well.
To allow that, we use the funding manager as the BatchCleaner
implementation.
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.
Because the RelevantBatchSnapshot RPC didn't return the raw batch
transaction at all, traders with a pending batch crashed here. We don't
necessarily need to know anything other than the transaction bytes here
so we might as well call the other RPC.
This commit aims to address another gap within the system to ensure
trader pending batch states are as accurate as possible. In a previous
commit, we addressed the case of a trader signing for a batch,
disconnecting and not receiving a Finalize message, and seeing a spend
for an account.
Here, we're interested in determining whether a batch a trader signed
for is actually still relevant to the trader. Since any trader can bail
from a batch, the batch may need to be re-done by the auctioneer, and if
a trader that previously signed for a previous version of the batch
remains disconnected, then they won't be aware of said new batch. At
this point, the trader has a lingering pending batch that's no longer
irrelevant, so we remove it. This logic is tied to the connection
establishment between the trader and auctioneer to ensure we handle the
disconnection and crash case of a trader after signing for a batch.
