Add API to get a callback when varlink connection goes away

[jonas2515]

When the connection to the server or the client goes away, and we're in the middle of a method call, it would be nice to be notified of that somehow (and then eg. cancel your ongoing action in a varlink server).

Currently there's no way to be notified of that early, and instead after the method call, reading the socket will return EOF.

Maybe there could be a API to get a CancellationToken on the ZlinkConnection?

[zeenix]

When the connection to the server or the client goes away, and we're in the middle of a method call, it would be nice to be notified of that somehow (and then eg. cancel your ongoing action in a varlink server).

All Connection methods will immediately return with an error if the peer disconnects.

Currently there's no way to be notified of that early, and instead after the method call, reading the socket will return EOF.

I'm not sure i follow. You're getting an error immediately if the other side disconnects. How can zlink possibly do anything faster/better? 🤔

Maybe there could be a API to get a CancellationToken on the ZlinkConnection?

As I tried to explain on the Matrix channel, I fail to see the relevant on cancellation here. This would be about cancellation of your own calls and with the low-level Connection API that you're using, you can already do this by just dropping the Future. For example you can use a timeout API with a call like in the simple example here: https://docs.rs/tokio/latest/tokio/time/fn.timeout.html#examples

[zeenix]

Just for the record (in case anyone wants to work on it), when I requested you to file this issue, I had misunderstood that you're using the Server API and need to be notified of clients connecting and disconnecting, which is something that would be very useful to have.

What I'm thinking is 2 methods, on_peer_connected and on_peer_disconnected on Server, that take:

1. mut self
2. an async callback whose only argument is a &Arc<connection::Credentials>>.

and return self (for allowing a builder pattern).

2 limitations:

1. Only one callback for each event per Server instance.
2. We'll need to fetch the Credentials on the first callback call.

I don't think either of these are a problem though.