protocols/gossipsub: implement the v1.4 large message extension (fragmentation with pipelined relay + PREAMBLE/IMRECEIVING)

Summary

GossipSub v1.4 (spec: libp2p/specs#654, design document: libp2p/specs#720) targets large-message propagation. It adds message fragmentation with fragment forwarding before full reassembly, plus PREAMBLE and IMRECEIVING signals that suppress duplicate pushes of in-flight messages. nim-libp2p and py-libp2p have prototypes. rust-libp2p has no implementation and, as far as I can find, no tracking issue.

I would like to put forth an implementation for the maintainers' consideration.

Motivation

Standard gossipsub relays store-and-forward: a relay must receive the full message before it forwards it. Delivery latency for a large message therefore grows with hop count times (size / bandwidth), and this term dominates above ~1 MB (Ethereum blobs and data columns, Waku, any large-payload topic).

Measured results from the two papers behind the spec:

• Fragmentation with pipelined relay: 56% dissemination-time reduction at 1 MB from fragmentation alone, more than 64% with all improvements combined, and roughly 6x lower latency spread (arXiv:2504.10365, nim-libp2p + Shadow simulations).
• PREAMBLE/IMRECEIVING: 45% bandwidth reduction at 400 KB, 61% above 1 MB, and up to 23% latency reduction for large messages (arXiv:2505.17337).

I also benchmarked stock gossipsub from current master at 4-10 MB payloads in a 10-node shaped-link harness. The delivery profile is serialization-bound, roughly two full hop-serializations at p50. Pipelined fragment relay is the mechanism that removes that term. The harness and the numbers can be found at https://github.com/MavenRain/gossipsub-baseline-bench.

Proposed scope (incremental, each step behind config)

1. Wire types and capability detection per the spec. Peers without v1.4 keep today's behavior.
2. Fragmentation and reassembly, with bounded reassembly buffers and an explicit fragment-size config (64 KB default per the design document).
3. Fragment forwarding before full reassembly, restricted to v1.4-capable peers, with the tentative-validity rules from the design document.
4. IMRECEIVING duplicate suppression, gated on message size (the paper reports a small latency regression below ~400 KB).

Default behavior does not change while the spec is under review.

Assumptions

• A prototype behind a non-default config flag is presently acceptable.
• Reassembly buffers and pre-validation forwarding add memory and withholding surfaces. The design document carries a threat model; Its bounds will be mirrored and the failure cases will be wired into peer scoring.

Start with libp2p/specs#654 and design document #720, then inspect the existing protocols/gossipsub implementation and its capability and configuration entry points. Done means the four proposed, config-gated stages are implemented, with bounded reassembly and threat-model limits, while peers without v1.4 retain current behavior.