feat!: improve error handling

[Frando]

This PR contains changes to error handling.

Currently, when the server receives a request that it cannot decode, it ends the connection unconditionally. handle_connection returns, and all other requests on the connection fail too. When a request is too large, the server closes the connection with code 1, and the client only sees "failed to read size".

Improve handling of bad requests

When the server cannot read a request, it now stops and resets the streams of that request. It uses code 1 if the request is too large, and the new code 3 (ERROR_CODE_DECODE_FAILED) if the request does not decode. The client of that request gets a clear error. What happens next depends on the server:

• Handler::handle_connection closes the connection with the same code, as for any other protocol violation.
• With Handler::skip_bad_requests(true), the handler reads the next request instead. This is for protocols that add request types over time.
• read_request and read_request_raw return the new ReadRequestError, so a server with its own loop decides. After MaxMessageSizeExceeded and InvalidRequest, the connection is still open and the server can read on. They return Connection when the connection fails, also in the middle of a request. They still return Ok(None) when the connection closes cleanly, now also when this side closed it. ReadRequestError converts into io::Error and iroh's AcceptError, so existing ? calls keep working.

Improve handling of bad channel messages

A remote oneshot::Receiver or mpsc::Receiver now stops its stream with code 3 when a message does not decode, so the sender learns why. For mpsc, this ends the channel. Before, a receiver could skip such a message and read the next one. We must make this change before 1.0, because after 1.0 it would break code that skips such messages. An option to skip them can come later.

Better error types

• Error, RequestError, WriteError, SendError, and both RecvErrors are #[non_exhaustive], so they can get new cases after 1.0.
• Code 2 is renamed from ERROR_CODE_INVALID_POSTCARD to ERROR_CODE_ENCODE_FAILED, to match ERROR_CODE_DECODE_FAILED.

Breaking changes

• changed: Error, RequestError, WriteError, SendError, mpsc::RecvError, and oneshot::RecvError are #[non_exhaustive]. Add a wildcard arm to matches.
• changed: read_request and read_request_raw return Result<Option<_>, ReadRequestError>, not io::Result<Option<_>>.
• changed: a server resets the streams of a bad request, then closes the connection with code 3 (does not decode) or code 1 (too large). Before, a request that does not decode dropped the connection with code 0.
• changed: a remote mpsc::Receiver stops its stream with code 3 if a message does not decode. Further reads fail, so a receiver can no longer skip such a message and read the next one.
• changed: rpc::ERROR_CODE_INVALID_POSTCARD is renamed to rpc::ERROR_CODE_ENCODE_FAILED.

[rklaehn]

Looks good overall. One real issue:

Reset streams are classified as InvalidRequest. read_failed only maps ReadError::ConnectionLost to Connection; everything else (incl. Reset, ClosedStream, ZeroRttRejected) becomes InvalidRequest. So a client that cancels an rpc() mid-write (easy with a large request) gets its stream stopped with code 3 "decode failed", and the default handler closes the whole connection with code 3. Suggest handling Reset (and probably ClosedStream/ZeroRttRejected) separately: no code 3, no connection close, just read the next request.

Smaller things:

• The default now actively close()s the connection, which kills in-flight responses in spawned handler tasks. Before, it just returned and the connection lingered while streams held refs. Fine as "protocol violation", but worth listing under breaking changes.
• The client doesn't map code 3 to a distinct error. It sees a generic io error (Reset(3)), or ConnectionLost(ApplicationClosed(3)) if the close wins the race.
• Minor inconsistency: LocallyClosed on accept_bi → Ok(None), but a local close mid-request → ReadRequestError::Connection.
• The 0–255 code reservation is doc-only; HandlerError doesn't check it.
• Maybe keep a #[deprecated] ERROR_CODE_INVALID_POSTCARD alias for the rename.
• No test for the too-large path (code 1).

[Frando]

Thanks. I pushed a few more commits.

• The client now resets streams when the future is dropped before the request was sent. On the server, a stream that was reset before the request was read is now skipped instead of reported as an error.
• I changed the docs that codes 0-15 are reserved, 0-255 seemed excessive. I'd still not enforce it, IMO it's enough to document this
• I improved the structure of the error enums a bit and made the handling more consistent.

Please give it another review.

[rklaehn]

Small PRs on top of this: #133 #134 #135

The general theme of these is that the behaviour with local mpsc streams and remote noq or iroh streams should be identical for the cases where we can clearly determine that the connection is not at fault.

[rklaehn]

My small PRs on top can be merged with this or later.