tx-submission decision logic for the inbound side

[coot]

To smooth traffic and save bandwidth, we can add a decision logic to inbound
tx-submission protocol which would decide from whom to download an available
transaction and trace which transactions are being downloaded (so we don't
start to download something that's already being downloaded).

todo list

• validate tx size
• validate that tx size is smaller than maximum tx size
• efficient adding txs to mempool (do not try add the same tx twice)
  Is this even needed? Mempool could check txids before doing any expensive validation.

[dcoutts]

This would be a design change with the following benefits:

1. substantially reduced bandwidth for tx broadcast
2. smoothing out refilling of the mempool to reduce bursty CPU and network use

This will be a useful optimisation as we get towards higher and higher chain throughput / TPS. For the moment (at current low TPS rates) it is not a significant issue. The effects are only visible in benchmarks with very high TPS.

[lehins]

Mempool could check txids before doing any expensive validation.

That would imply that we have all applied TxIds available in the ledger state, which we do not want to do, since that would blow up ledger state drastically.

We could keep some TxIds for a period of time and then expire old ones. Which we might need to implement for Leios anyways. For now we've implemented a simple check whether all of the inputs have been spent in a transaction and if all of them are gone, that is a good indicator that that same transaction was already included at which point we short-circuit validation: IntersectMBO/cardano-ledger#4967