Check that the transactions submitted at the mempool have a valid size

[dnadales]

We should change the mempool admission test from:

mempoolsize + txsize <= mempoolcapacity

to:

mempoolsize < mempoolcapacity

This would mean that as soon as there is a byte free in the mempool we add a transaction to it.

We should look out for invariants that assume that mempoolsize <= mempoolcapacity always hold.

We expect that the ledger checks the sanity of the transactions' size. We should document this expectation somewhere.

The mempool admission check can be found here.

This change should take place on top of IntersectMBO/ouroboros-network#4436.

[dnadales]

We should look out for invariants that assume that mempoolsize <= mempoolcapacity always hold.

Upon inspection of the code, it seems that this cannot possibly be an invariant. The mempool API states that the maximum capacity can dynamically change when the ledger state is updated.

-- Note that the capacity of the Mempool, unless it is overridden with
-- 'MempoolCapacityBytesOverride', can dynamically change when the
-- ledger state is updated: it will be set to twice the current ledger's
-- maximum transaction capacity of a block.

The code can't possibly rely on mempoolsize <= mempoolcapacity because:

-- When the capacity happens to shrink at some point, we /do not/ remove
-- transactions from the Mempool to satisfy this new lower limit.

[dnadales]

Changes pushed to IntersectMBO/ouroboros-network#4436

[nfrisby]

While working on PR #1175, Esgen noticed that I had reverted the change suggested in this Issue's description. After some study, I think it's OK to revert that change.

Specifically: PR #49 made both the change suggested by this Issue's description as well as adding some centralized MVars. I believe those MVars supplant the description's suggested change: as soon as a thread adding a tx grabs the MVar, it will hold it until that tx fits in the mempool.

[amesgen]

For posterity: There actually is an important reason why this change needed to be a part of #49: Otherwise, transactions that have a larger byte size than the mempool capacity would cause a deadlock, as they will never satisfy the mempoolsize + txsize <= mempoolcapacity predicate, and no other tx can enter the mempool due to the extra locks added in #49.

However, reverting this in #1175 is fine as that PR also adds the per-tx size limit check in this place, making sure that transactions that exceed the mempool capacity (which is at least one block) are immediately rejected.

Also see #1225 for a related change.