consensus: use distinct types for validated and unvalidated transactions

This is necessary for Alonzo. But, as for everything else, Consensus integrates
it generally, not just for Alonzo.

The root changes are as follows:

  * introduce the `Validated` data family

  * change the result of `applyTx` to include a `Validated`; `applyTx` is _the_
    proper way to constructor a `Validated (GenTx blk)` value

  * change the argument of `reapplyTx` to use `Validated`

Everything follows from those changes. In particular, we must update the
mempool to hold _validated_ transactions and, relatedly, the block forging
routines to now take a sequence of _validated_ transactions. Note that we still
only send/receive unvalidated transactions (no peer can trust another's
validation), so `TxSub` still only handles unvalidated transactions. Thus we
need the `txForgetValidated` method as well.

At least for now, we have no cause to send/receive validated transactions. Thus
we do not need serialization for validated transactions.

Note that we to translate both unvalidated and validated transactions from one
era to the next.

  * Unvalidated for the same reasons as before: a transaction might be sent
    before the boundary but only be received after the boundary.

  * For validated, it's much the same idea. A transaction might have entered
    the mempool before the boundary but will only be baked into a block after
    the boundary. (At some point the mempool will " reapply " its contents to a
    new era ledger state, and that requires the translation of validated
    transactions.)

We define 'Validated' as an independent data family because we plan to re-use
it for blocks as well. Validated-ness is a fundamental concept, much liked
'Ticked', and so we encode it as a fundamental building block. The use of a
data family also brings the usual type inference benefits as well as forcing us
to respect the (intentionally emphasized!) distinction even in definitions that
have monomorphic block types (where the unvalidated and validated transaction
types in the ledger might be nominally equivalent).

ouroboros-consensus-test/test-consensus/Test/Consensus/MiniProtocol/LocalStateQuery/Server.hs

@@ -49,7 +49,6 @@ import           Test.QuickCheck hiding (Result)
 import           Test.Tasty
 import           Test.Tasty.QuickCheck
 
-import           Ouroboros.Consensus.Ledger.Query (Query (..))
 import           Test.Util.Orphans.IOLike ()
 import           Test.Util.TestBlock
 

ouroboros-consensus/src/Ouroboros/Consensus/Mempool/API.hs

@@ -23,6 +23,9 @@ module Ouroboros.Consensus.Mempool.API (
     -- * Tracing support
   , TraceEventMempool (..)
   , addTxs
+  , isMempoolTxAdded
+  , isMempoolTxRejected
+  , mempoolTxAddedToMaybe
     -- * Re-exports
   , TxSizeInBytes
   ) where