feat(rust/core): add async traits

[if0ne]

It’s not a duplicate of #3714. It’s actually part of #3714 and adds async traits for Driver, Database, Connection, and Statement.

For now, I’ve excluded the DataFusion driver. We need a new version of DataFusion that supports arrow crates version 58.

UPD: I'm waiting for the DataFusion release with these changes: apache/datafusion#19728

[if0ne]

@lidavidm @eitsupi

Should we raise the minimum supported version for the arrow crates to 58.0.0 if we want to use the async feature from arrow?

[eitsupi]

I suppose you want to mean apache/arrow-rs#9166.
If we use this, it seems that we will definitely need to select arrow 58.0.0 or later.

[lidavidm]

Is it possible in Cargo.toml to only enforce the higher minimum version when the async feature is enabled, and leave it lower otherwise?

That said, I don't think I object in general to requiring a newer Arrow, but I'm not sure if users would find that inconvenient. I would think people try to use the newest versions where possible, so maybe it's not a big issue?

[if0ne]

Is it possible in Cargo.toml to only enforce the higher minimum version when the async feature is enabled, and leave it lower otherwise?

As far as I know, it is not possible.

[if0ne]

@eitsupi @lidavidm

Please take a look at the PR

[lidavidm]

Thanks, looks straightforward to me. Cancellation should probably consider something like #3905 but we can work that out later as well

[abonander]

Strictly speaking, cancellation in Rust is as straightforward as just dropping the Future. The implementation is supposed to automatically cancel any in-flight operations when that happens.

Though to be fair, cancellation is not very well explained in the official documentation. The chapter on cancellation in the async book is just a stub: https://rust-lang.github.io/async-book/part-reference/cancellation.html

[lidavidm]

The problem is what to do about FFI - dropping the Future seems quite a bit more complicated from that layer and having some way to explicitly request a cancellation (causing the outstanding futures to resolve to an error) seems easier to implement. My proposal so far has been to have something akin to a cancellation token (as Go and other ecosystems effectively do), which that page very briefly acknowledges.