Implement client-side timeouts

[psarna]

In certain cases (e.g. when a node dies) it's important to be able to set a client-side timeout which gives up on a request after specified time - and optionally retries on another connection. While at it, it's very important to remember that stream_ids must not be reused right after client-side timeout occurs - otherwise, future requests might receive responses directed to some other request that timed out.

[piodul]

It is possible to cancel requests right now, without the driver's explicit support for timeouts. You can just stop waiting for the future returned by e.g. session.execute() - this should work:

tokio::time::timeout(Duration::from_secs(10), session.execute(statement));

In the meantime, the stream ID won't be removed until the response arrive from the node.

[kbr-]

In the meantime, the stream ID won't be removed until the response arrive from the node.

Which it never may e.g. due to shedding, so we can leak stream IDs and channels (they will keep using memory until the connection is closed).

[piodul]

In the meantime, the stream ID won't be removed until the response arrive from the node.

Which it never may e.g. due to shedding, so we can leak stream IDs and channels (they will keep using memory until the connection is closed).

Yes. It would be nice to fix this along with the following issue: #305 - we could remove the oneshot channel from the handler map when the corresponding future is removed. The stream ID would still be kept allocated in the stream ID bitmap until the response arrives, or until the connection is closed if the request was shed.

[psarna]

@wprzytula let's consider the following granularity:

1. session-wise request_timeout parameter
2. prepared-statement-wise timeout parameter, which takes precedence over the per-session one, but if it's not present, then the default one from the session is used