P2P controller hardening

[kalabukdima]

Closes #25

Transport layer

Replace request-response behaviour with a much simpler and more flexible stream behaviour. Benefits:

• Protobuf parsing used to run deep inside the transport lib. Now the worker parses the messages, simplifying the flow.
• Instead of passing the result back to the transport under the global swarm lock, each request handler can now write the response or drop the stream independently.
• No hidden limits and dropped connections.
• Manual timeout handling for reads and writes separately.
• It opens the road for multipart/streaming responses instead of a single protobuf message.

See subsquid/sqd-network#211

Handling backpressure

Now there is a synchronous event loop pulling events (stream requests) from the transport layer. It quickly checks if the client is allowed to send the request and spawns a processing tokio task or sends the rejection to the client. If this loop can't keep up with the incoming requests, extra requests will get dropped before being parsed.

This is not perfect because it doesn't propagate the backpressure to cut the early handshake. The full incoming stream is still read to memory. But making it perfect requires a significant reorg of the libp2p stack and isn't directly supported by existing libp2p behaviours.

Graceful rejections

In many cases the stream was dropped without sending any bytes. The client just saw a "connection reset" which was difficult to diagnose. Try to return a meaningful rejection now. Only drop the stream if there are too many in-flight rejections or the response couldn't be written.

Scenario	Response	Log	Used CU
Undecodable query	connection reset (no query_id to sign)	none	0
Invalid signature	connection reset → BadRequest("invalid query signature")	none	0
Timestamp out of range	connection reset → BadRequest("timestamp out of allowed range")	none	0
Queue full (backpressure)	connection reset → ServerOverloaded + backoff	none	0
No allocation	TooManyRequests	none	0
Rate limited (paused)	TooManyRequests + retry	none	0
Malformed params (bad compression / missing block_range)	BadRequest	BadRequest	0 → 1
Success, delivered	Ok	Ok summary	chip²
Success, signing fails	connection reset → ServerError("failed to sign query result")	Ok summary → ServerError	chip²
Success, result too large	connection reset → ServerError("query result too large")	Ok summary → ServerError	chip²
Success, transport send-buffer full	connection reset → Ok (delivered) ¹	Ok summary	chip²
NotFound (no chunks in range)	NotFound	NotFound	chip²
Engine overloaded (ServiceOverloaded)	ServerOverloaded + backoff	ServerOverloaded	0 → chip²
Internal engine error (Other)	ServerError	ServerError	chip²

¹ The old transport had an internal send queue that could reject a perfectly good result. stream_server's ResponseSender writes to the stream directly, so that queue no longer exists; the result is delivered (a reset now only happens if the client itself is gone or the write times out).
² chip = the query's overlap fraction with the chunk (1 for a full-chunk query); the flat 1.0 is claimed at admission and the unused part refunded, so a served query's charge is chip.