Add Framing/JsonFraming throughput and allocation benchmarks

[Aaronontheweb]

Summary

Adds a new FramingBenchmarks class to Akka.Benchmarks that measures throughput and per-frame allocation overhead for the four hot paths in the framing system:

• LengthField_Encode — Framing.SimpleFramingProtocolEncoder (4-byte big-endian length prefix + payload)
• LengthField_Decode — encode→decode round-trip through SimpleFramingProtocol
• Delimiter_Decode — Framing.Delimiter over a stream of single-message-per-chunk inputs
• JsonFraming_MultiChunk — JsonFraming.ObjectScanner with chunks deliberately sized to straddle object boundaries (so most Offer calls into JsonObjectParser concatenate into a non-empty buffer)

Why this PR

The framing stages have always been suspected of being allocation-heavy on the per-message path (the parsedFrame.ToArray() / _buffer.ToArray() defensive compactions, the encoder's Concat byte[] allocation, and the JSON parser's merge byte[] in non-empty Offer). There is no BenchmarkDotNet coverage of the framing paths today, so any change in this area has to be evaluated against indirect signal (the TCP echo benchmark, the NBench JsonFramingBenchmark).

This adds direct, comparable BDN numbers — the same harness shape used by TcpOperationsBenchmarks / StreamThroughputBenchmarks — so future framing changes can be measured cleanly.

Benchmark design

The benchmark uses a deferred-source pattern so all materializer overhead sits outside the measurement window:

[IterationSetup(Target = nameof(LengthField_Encode))]
public void Setup() {
    _gate = new TaskCompletionSource<NotUsed>(TaskCreationOptions.RunContinuationsAsynchronously);
    _completion = Source.FromTask(_gate.Task)
        .ConcatMany(_ => Source.From(_rawMessages))
        .Via(Framing.SimpleFramingProtocolEncoder(int.MaxValue))
        .RunWith(Sink.Ignore<ByteString>(), _materializer);
}

[Benchmark(OperationsPerInvoke = MessageCount)]
public Task LengthField_Encode() {
    _gate.SetResult(NotUsed.Instance);
    return _completion;
}

The graph materializes during IterationSetup — actors spawn, stages fuse, the dispatcher attaches, the sink subscribes — and parks waiting on the TCS. The benchmark method only trips the gate and awaits drain. With OperationsPerInvoke = 10000, the two fixed hops (gate-signal + sink-complete) amortize to noise and the reported Allocated column reads as bytes-per-framed-message.

For JsonFraming_MultiChunk, input chunks are sized at MessageSize / 3 so every chunk crosses at least one object boundary. This exercises the multi-Offer concatenation path inside JsonObjectParser rather than the empty-buffer fast path.

Parameters

• MessageSize ∈ {64, 1024} bytes
• MessageCount fixed at 10,000

8 cells total. Wall-clock under Job.Default (BDN's chosen warmup/iterations) is well under 10 minutes on a modern machine.

Test plan

• Smoke run with --job dry confirms the benchmark executes end-to-end on dev (already verified locally)
• Full run with default job to capture baseline numbers
• Numbers can then be compared against framing-related changes on feature branches

Notes

Ports the same FramingBenchmarks.cs will need to be backported (with ByteString → ReadOnlyMemory<byte> / ReadOnlySequence<byte> adaptations) to feature branches that change the underlying byte-buffer type. The benchmark structure stays identical; only the type name changes.