Return error from subscription callbacks

[lexnv]

Subscription callbacks are now returning errors for improved ergonimics.

The jsonrpsee proc-macro renders the provided subscription method with
an additional return type.

#[rpc(client, server, namespace = "foo")]
pub trait Rpc {
	#[subscription(name = "subscribe", item = String)]
	fn sub(&self);
}


#[async_trait]
impl RpcServer for RpcServerImpl {
	fn sub(&self, pending: PendingSubscription) -> ReturnTypeSubscription {
		Ok(())
	}

While at it, implement pipe_from_try_stream on the PendingSubscription for better ergonomics,
which wraps the pending.accept() and pipes from the provided stream.

Before

.register_subscription("sub_one_param", "sub_one_param", "unsub_one_param", |params, pending, _| {
    let idx = match params.one::<usize>() {
        Ok(idx) => idx,
        _ => {
            pending.reject("some special error);
            return;
        }
    };
    tokio::spawn(async move {
        if let Some(sink) = pending.accept() {
             sink.pipe_from_try_stream(stream).await;
             // ...
        }
    });
    Ok(())
}

After

.register_subscription("sub_one_param", "sub_one_param", "unsub_one_param", |params, pending, _| {
    let idx = match params.one::<usize>()?;

    tokio::spawn(async move {
        pending.pipe_from_try_stream(stream).await;
        // ...
    });
    Ok(())
}

Closes #734, #735.

[niklasad1]

nice work

[jsdw]

Looks good; the unified sink stuff def feels nicer API wise!

My only real blocker is that I don't think we should have accept() and maybe_accept() (the difference is confusing and one call can express enough info to use in both places). The other comment was an internal API nit so doesn't matter so much.

[Xanewok]

That looks like a great ergonomics boost, nice! Left some drive-by notes, don't want to comment on the internals yet.

[Xanewok]

I think a simple two-variant enum could help understand what the bool returned from send_error specifically means

[niklasad1]

Agree I think it was designed like that to be easy convert to "success/or not" in the middleware but it's unrelated this PR.

Let's tackle it another PR.

[niklasad1]

LGTM, some minor comments that are optional to fix.

Would be nice to have some abstraction that decouples the state of the SubscriptionSink which includes inner method sink, unsubscribe future and close_notify somehow.

I have been thinking that we could just use tokio::sync::mpsc::unbounded_channel instead futures::mpsc::unbounded_channel and tokio::sync::Notify as the sender in tokio has async fn closed which returns once the receiver has been dropped which would cancel each subscription on that connection.

That would simplify the SubscriptionSink slighty :P

[jsdw]

LGTM, well done!