Cardano Updates

From https://github.com/IntersectMBO/cardano-cli at 796f79f01fe084ade4731ab785292a76fbf04c1d

Signed-off-by: Matthieu Pizenberg <[email protected]>

Signed-off-by: Matthieu Pizenberg <[email protected]>

Three info! lines fire once per item under steady cluster load and
together accounted for ~600K of the ~660K info-level log lines in a
27-minute test run, dominating disk usage:

  - `transaction received` (net-node)         366K lines
  - `network event` (net-node, default arm)   155K lines
  - `mempool: evicting oldest tx` (shared)     71K lines

At a 1 tx/s/node generation rate with a 10K-cap mempool, the
eviction line fires on every admit once the cap is reached.  At
RUST_LOG=info on a 25-node cluster these saturate disk in roughly
half a day.

None of the three is useful at info: the per-tx and per-event lines
are item-level traces (debug territory) and eviction at cap is a
steady-state condition, not a notable event.  Periodic
`mempool state sizes` / `praos state sizes` / `leios_store: stats`
lines remain at info — those carry the diagnostic signal.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

`LeiosStore::notifications: Vec<LeiosNotification>` was never pruned.
Every `inject_block` / `inject_block_txs` / `inject_votes` pushed an
entry that lived forever, even though the blocks/votes those entries
point at get slot-window-evicted by the same `bump_version` call.
Over a long-running cluster the vec grows monotonically with the
total inject rate.

Switch storage to `VecDeque` and add a `notifications_pruned_count`
so logical (caller-facing) cursors stay monotonic across pruning.
At slot-window eviction, front-prune notifications whose every
referenced slot is below the cutoff — those refer to data the store
no longer holds, so re-sending them to a subscriber would be a
wasted round trip.  Stop at the first non-evictable front entry:
notifications arrive in roughly slot order, so the leak past the
cutoff is bounded by out-of-order arrivals (next bump catches up).

`notifications_after` now takes `&mut usize`.  Callers track a
monotonic logical cursor; if it lags the prune frontier the call
bumps it forward so subsequent `*after += 1` increments stay aligned
with the items actually consumed.  `notification_count` reports the
all-time logical total.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The demuxer enforces `set_ingress_limit` as a *buffer* cap on the
per-protocol ingress queue, not as a per-message cap.  Under server
pipelining (`MsgStartBatch` immediately followed by `MsgBlock`) both
segments can land in the buffer before the codec processes
`MsgStartBatch` and bumps the limit for `StStreaming`.  With the
prior per-state caps that race manifested two ways:

  1. `StBusy` at `SIZE_LIMIT_SMALL = 65_535` rejected the pipelined
     block body outright (a 65K+ block was already enough to trip
     it).
  2. Even with `StBusy` raised to `SIZE_LIMIT_STREAMING = 2.5 MB`,
     a real Praos block body — particularly the post-EB-overflow
     fallback path where txs the EB couldn't carry get inlined into
     the RB — can legitimately exceed 2.5 MB.  Overnight one landed
     at 2,506,268 bytes and tripped the new cap, cascading SDU
     timeouts and freezing the cluster.

The spec defines `INGRESS_LIMIT = 230 MB` as the per-protocol
ingress buffer cap exactly for this case.  Use it for both `StBusy`
and `StStreaming`.  Spec per-message rejection at
`SIZE_LIMIT_SMALL` / `SIZE_LIMIT_STREAMING` belongs in the codec at
decode time (not yet wired); the framework's `size_limit` callback
controls buffer sizing only.

`StIdle` keeps `SIZE_LIMIT_SMALL` — the client never receives in
that state, so the tighter cap stands.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

`MempoolState::peek_unannounced_for_peer` used to scan the entire
`txs` queue on every call, doing a `BTreeSet<TxId>::contains` check
per element to find the few ids the peer hadn't yet been told about.
Under steady TxSubmission pull traffic with a caught-up peer that's
`O(N · log A · 32)` per poll for no useful work — the dominant
mempool-CPU symptom under cluster load.

Flip the polarity: keep a per-peer "still owed to this peer"
`BTreeSet<TxId>` that's the inverse partition of `peer_advertised`
over the current mempool.  Lazily seed it from `tx_index` on first
peer-facing call; admit fan-out inserts the new id into every known
peer's owed set; pruning (`drain_*`, `on_block_applied`, capacity
eviction) drops the id from both sides; `forget_peer` clears both.

The hot path becomes: look up the peer's owed set (`O(log P)`),
return immediately if empty, otherwise drain up to `max_count` and
resolve bodies.  The remaining `for tx in &self.txs` scan only runs
when there's actually unannounced work — the empty-poll case (which
dominates under steady-state cluster traffic) returns without
touching the queue.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Signed-off-by: Sasha Bogicevic <[email protected]>

Docker build workflows

Signed-off-by: Matthieu Pizenberg <[email protected]>

Signed-off-by: Eric Torreborre <[email protected]>

Signed-off-by: Eric Torreborre <[email protected]>