txorphanage: account memory usage instead of weight #36015

Drop includes the header does not use, add the ones it does, and forward
declare FastRandomContext. The IWYU job checks the files a change touches,
and the following commits modify this header.

This constant is the default for TxOrphanage::m_reserved_usage_per_peer,
returned by ReservedPeerUsage() and compared against UsageByPeer(), so
name it after the quantity it limits rather than after the metric that
happens to be used to measure it. A following commit changes that metric
from weight to memory usage.

-BEGIN VERIFY SCRIPT-
sed -i 's/DEFAULT_RESERVED_ORPHAN_WEIGHT_PER_PEER/DEFAULT_RESERVED_ORPHAN_USAGE_PER_PEER/g' $(git grep -l DEFAULT_RESERVED_ORPHAN_WEIGHT_PER_PEER)
-END VERIFY SCRIPT-

The orphanage's notion of an orphan's "usage" is currently duplicated in
the unit tests, the benchmarks and the fuzz targets, all of which call
GetTransactionWeight() to predict what the orphanage will account. Move
that knowledge into a single function so that a change of metric only
has to happen in one place, and so that all users agree on it.

Also cache the value in the Announcement instead of recomputing it on
every operation. Announcements hold an immutable CTransactionRef, so the
value never changes; caching it guarantees that PeerDoSInfo::Add() and
::Subtract() always use the same number, and makes Erase() (and therefore
LimitOrphans()) independent of the transaction's size.

No behavior change.

The orphanage limits the "usage" of the orphans it stores, per peer and
globally, to bound the amount of memory an attacker can make us hold on
to. Weight was used as a proxy for that memory, on the assumption that it
is "often higher than the actual memory usage of the transaction".

That assumption does not hold. Every witness stack element is an
individually heap-allocated vector, costing its 24-byte slot in the stack
vector plus a 32-byte minimum allocation, while only weighing 2WU. A
transaction of 199,000 1-byte witness elements weighs 398,247WU (i.e. it
is a standard weight, and witness standardness cannot be checked while
the inputs are missing), but uses 11.1MB of memory: 28 times what is
accounted for it.

Account the memory the transaction actually uses instead, and derive the
per-peer reservation from the largest orphan we are willing to store, so
that a peer relaying one maximally-sized orphan still stays within its
allowance (and therefore cannot cause any evictions). Orphans that would
not fit in that allowance are now refused by AddTx() rather than stored
and immediately evicted again by LimitOrphans(), which would first push
out the announcer's other orphans: with weight accounting, a peer that
had 10 normal orphans and relayed one maximally-sized one kept 9 of them;
accounting memory without the new limit would leave it with none.

Add unit tests for what changed with accounting memory instead of weight:

- orphan_usage_limits: an orphan's contribution to the peer's usage is its
  memory usage; transactions that are small by weight but memory-dense do
  fill up a peer's allowance; the largest storable orphan fits within a
  peer's reserved usage (alongside normal orphans) and one witness element
  more is refused.
- witness_heavy_orphan_tx: a standard-weight transaction consisting of
  199,000 1-byte witness elements uses over 10 times its weight in memory
  and is not stored, neither on its own (leaving the announcer's other
  orphans in place) nor by announcing one per peer.
- large_standard_orphan_tx: transactions of maximum standard weight with
  realistically-shaped witnesses are still stored, and do not evict the
  announcer's other orphans.

Check over p2p that memory usage and not weight is what fills up a peer's
allowance (three memory-dense but featherweight orphans fit, the fourth
evicts the oldest), that an orphan using more memory than allowed is not
stored (neither on its own, without disturbing the announcer's other
orphans, nor once per connection), and that an orphan of maximum standard
weight is still stored.

Without accounting memory, the first of these keeps all four orphans and
the second keeps a ~1MB orphan per connection in the orphanage forever.

test_maximal_package_protected() builds an ancestor package of the maximum
allowed 404,000WU and relies on it fitting inside what the orphanage
reserves for a peer, which is what keeps it from being evicted while other
peers spam. Now that the reservation is an amount of memory rather than of
weight, that is no longer apparent from the package's weight.