Add Batch messages from processor, verify Batchs published on-chain

Renames Update to SignedBatch.

Checks Batch equality via a hash of the InInstructions. That prevents needing
to keep the Batch in node state or TX introspect.

docs/processor/Processor.md

@@ -6,7 +6,7 @@ transactions with payments.
 
 This document primarily discusses its flow with regards to the coordinator.
 
-## Generate Key
+### Generate Key
 
 On `key_gen::CoordinatorMessage::GenerateKey`, the processor begins a pair of
 instances of the distributed key generation protocol specified in the FROST
@@ -20,26 +20,26 @@ Serai's overall key generation protocol.
 The commitments for both protocols are sent to the coordinator in a single
 `key_gen::ProcessorMessage::Commitments`.
 
-## Key Gen Commitments
+### Key Gen Commitments
 
 On `key_gen::CoordinatorMessage::Commitments`, the processor continues the
 specified key generation instance. The secret shares for each fellow
 participant are sent to the coordinator in a
 `key_gen::ProcessorMessage::Shares`.
 
-### Key Gen Shares
+#### Key Gen Shares
 
 On `key_gen::CoordinatorMessage::Shares`, the processor completes the specified
 key generation instance. The generated key pair is sent to the coordinator in a
 `key_gen::ProcessorMessage::GeneratedKeyPair`.
 
-## Confirm Key Pair
+### Confirm Key Pair
 
 On `substrate::CoordinatorMessage::ConfirmKeyPair`, the processor starts using
 the newly confirmed key, scanning blocks on the external network for
 transfers to it.
 
-## Connected Network Block
+### External Network Block
 
 When the external network has a new block, which is considered finalized
 (either due to being literally finalized or due to having a sufficient amount
@@ -48,8 +48,14 @@ of confirmations), it's scanned.
 Outputs to the key of Serai's multisig are saved to the database. Outputs which
 newly transfer into Serai are used to build `Batch`s for the block. The
 processor then begins a threshold signature protocol with its key pair's
-Ristretto key to sign the `Batch`s. The protocol's preprocess is sent to the
-coordinator in a `coordinator::ProcessorMessage::BatchPreprocess`.
+Ristretto key to sign the `Batch`s.
+
+The `Batch`s are each sent to the coordinator in a
+`substrate::ProcessorMessage::Batch`, enabling the coordinator to know what
+`Batch`s *should* be published to Serai. After each
+`substrate::ProcessorMessage::Batch`, the preprocess for the first instance of
+its signing protocol is sent to the coordinator in a
+`coordinator::ProcessorMessage::BatchPreprocess`.
 
 As a design comment, we *may* be able to sign now possible, already scheduled,
 branch/leaf transactions at this point. Doing so would be giving a mutable
@@ -57,26 +63,26 @@ borrow over the scheduler to both the external network and the Serai network,
 and would accordingly be unsafe. We may want to look at splitting the scheduler
 in two, in order to reduce latency (TODO).
 
-## Batch Preprocesses
+### Batch Preprocesses
 
 On `coordinator::CoordinatorMessage::BatchPreprocesses`, the processor
 continues the specified batch signing protocol, sending
 `coordinator::ProcessorMessage::BatchShare` to the coordinator.
 
-## Batch Shares
+### Batch Shares
 
 On `coordinator::CoordinatorMessage::BatchShares`, the processor
 completes the specified batch signing protocol. If successful, the processor
-stops signing for this batch and sends `substrate::ProcessorMessage::Update` to
-the coordinator.
+stops signing for this batch and sends
+`substrate::ProcessorMessage::SignedBatch` to the coordinator.
 
-## Batch Re-attempt
+### Batch Re-attempt
 
 On `coordinator::CoordinatorMessage::BatchReattempt`, the processor will create
 a new instance of the batch signing protocol. The new protocol's preprocess is
 sent to the coordinator in a `coordinator::ProcessorMessage::BatchPreprocess`.
 
-## Substrate Block
+### Substrate Block
 
 On `substrate::CoordinatorMessage::SubstrateBlock`, the processor:
 
@@ -89,13 +95,13 @@ On `substrate::CoordinatorMessage::SubstrateBlock`, the processor:
 4) Sends `sign::ProcessorMessage::Preprocess` for each plan now being signed
    for.
 
-## Sign Preprocesses
+### Sign Preprocesses
 
 On `sign::CoordinatorMessage::Preprocesses`, the processor continues the
 specified transaction signing protocol, sending `sign::ProcessorMessage::Share`
 to the coordinator.
 
-## Sign Shares
+### Sign Shares
 
 On `sign::CoordinatorMessage::Shares`, the processor completes the specified
 transaction signing protocol. If successful, the processor stops signing for
@@ -104,7 +110,7 @@ this transaction and publishes the signed transaction. Then,
 broadcasted to all validators so everyone can observe the attempt completed,
 producing a signed and published transaction.
 
-## Sign Re-attempt
+### Sign Re-attempt
 
 On `sign::CoordinatorMessage::Reattempt`, the processor will create a new
 a new instance of the transaction signing protocol if it hasn't already
@@ -112,7 +118,7 @@ completed/observed completion of an instance of the signing protocol. The new
 protocol's preprocess is sent to the coordinator in a
 `sign::ProcessorMessage::Preprocess`.
 
-## Sign Completed
+### Sign Completed
 
 On `sign::CoordinatorMessage::Completed`, the processor verifies the included
 transaction hash actually refers to an accepted transaction which completes the