Benchmarking: remaining scenario types (actor, object, fanout, failure, mixed)

[dahlia]

Note

Sub-issue of #744. Before reading further, read #744 in full, including all of its comments, where the benchmarking tool's design is worked out in detail. This issue is one slice of that design and assumes the decisions recorded in those comments.

This is step 4 of 5. It depends on #784 (and on #782 for the trigger endpoint).

Scope

actor and object (read paths)

• actor: actor-document fetch, the document other servers fetch first to verify a signature (generating it assembles the key pairs, so it is a real generation path, not a static file). Discovered by handle. signed selects anonymous or authenticated fetch.
• object: source is either a sequence of explicit URLs, or a crawl mapping (seed actor handle, collection in outbox/featured/liked, limit, optional type filter; scalar-or-list throughout). Crawling harvests real object URLs from the actor's collections over standard ActivityPub, with no cooperative endpoint. signed selects anonymous or authenticated fetch, since dispatchers can gate access with an authorize predicate.

fanout (outbound)

• Stands up benchmark-owned sink inboxes (counting, with optional injected latency/errors via sinkBehavior), passes them as explicit recipients to the trigger endpoint, and measures queue drain. Fanout uses Fedify's two-stage queue (one fanout task expands into one outbox task per inbox), so the recipient count must reach the fanout threshold of 5 (or fanout: force) to exercise the queue. Drain completion is read from the queue counters in stats (enqueued - (completed + failed) reaching zero) and the depth gauge, bounded by queueDrainTimeout. The queue backend is a knob, to answer whether drain changes across SQLite, PostgreSQL, Redis, or in-process. No real fediverse side effects.

failure and mixed

• failure: fault injection (invalid signature, missing actor, remote 404/410, slow inbox, network error); some inbound (a bad signature to the inbox), some outbound (a slow or failing sink exercises retry).
• mixed: several scenarios run concurrently with weights, to surface contention bottlenecks that a single-type run misses.

Dependencies

Depends on #784 (the runnable tool and scenario plumbing) and #782 (fanout uses the trigger endpoint).

Acceptance criteria

• actor and object (both source forms, anonymous and signed) are implemented.
• fanout triggers a burst to benchmark-owned sinks and reports queue drain and delivery throughput, with no real fediverse side effects.
• failure covers the documented fault kinds.
• mixed runs a weighted concurrent blend.

Documentation

Add a section per scenario type to docs/manual/benchmarking.md.