Send small records in a RECORDS frame: 1 or 2 bytes of framing each, not 19

A RECORD frame carries a number, a size, an offset and a length before
each record's bytes, 19 bytes: a packet held 13.7 records of 61 bytes. A
RECORDS frame (0x06) carries the first record's number and a count, then
whole records whose numbers follow on, each its size as a varint and its
bytes: 17.2 a packet. A piece of a record larger than a piece still goes
in a RECORD frame; a receiver takes both.

The transport alone (research/experiments/019-idle-links/transport.c)
drains 200,000 records of 61 bytes in 11,600 packets instead of 14,600;
per record the link takes 0.217 us and the listener 0.23, 0.447 us in all,
against quinn's 0.43 a message over one stream.

1 files changed, 6 insertions, 0 deletions

diff --git a/serve/link.h b/serve/link.h
index b831ab4..5d4a746 100644
--- a/serve/link.h
+++ b/serve/link.h
@@ -38,6 +38,12 @@
  *                not taken: send what follows it again), u32 credit (records
  *                it takes past that)
  *   0x05 PING    to be acknowledged
+ *   0x06 RECORDS u64 the first one's number, u8 count, then whole records one
+ *                after another (numbers following on), each its size (a
+ *                varint: LEB128) and its bytes: small sends, 1 or 2 bytes
+ *                of framing each, not the 19 of RECORD
+ *   0x00 PADDING to the end of the packet: a full packet sent in a burst is
+ *                a whole datagram
  * Losses are detected as RFC 9002 says; congestion control is its NewReno
  * (RFC 9002 §7). */