Implement cass_cluster_set_num_threads_io

[dkropachev]

[muzarski]

Some context:
In cpp-driver, this configures the number of threads in a thread pool that handles the requests (it is shared between all connections!!!). In rust-driver case, we don't have anything like this - the number of threads is controlled by the underlying tokio runtime. Rust-driver creates tokio tasks that handle the requests - two per connection (reader and writer).

A reasonable way to implement this feature would be to configure the tokio runtime to use specified number of threads. There is one problem, though.

Currently, the cpp-rust-driver uses a static global tokio Runtime initialized using LazyLock. The runtime object is not tied to the cluster object (user could have many of those, to open different sessions with different settings).

From what I saw, it is possible to have multiple tokio runtimes in one application. This is useful if someone wants to isolate the asynchronous logic between different parts of code. This is exactly our use-case - user might want to have different number of worker threads per session.

So to summarize, I think we should have a tokio runtime per-cluster/session.

[dkropachev]

@Lorak-mmk , @wprzytula , another proposal regarding this API:

1. Have default runtime with tokio defaults
2. Have an API to create tokio runtim
3. Have cass_cluster_* API to override runtime on the cluster instance
4. Depricate cass_cluster_set_num_threads_io

It is more flexible solution than cass_cluster_set_num_threads_io

[wprzytula]

@Lorak-mmk , @wprzytula , another proposal regarding this API:

1. Have default runtime with tokio defaults

Makes sense.

2. Have an API to create tokio runtim

WDYM? Any more specific suggestions how would such API look like?/

3. Have cass_cluster_* API to override runtime on the cluster instance

Again, please provide example pseudocode.

4. Depricate cass_cluster_set_num_threads_io

Why? Isn't it exactly what we'd like to do about configuring the tokio runtime - the number of executor threads?

It is more flexible solution than cass_cluster_set_num_threads_io

It has potential to be more flexible, but only if we introduce more methods. Even having cass_cluster_set_num_threads_io(), we can add more methods alongside and get this flexibility.

To sum up, I need more specific suggestions of the new API methods.

[Lorak-mmk]

The goal of the project is to be compatible with original cpp-driver. We should have a very good reason to break compatibility. I personally don't think that cass_cluster_set_num_threads_io is a bad API and thus I don't see a reason to break it.

Two possible semantics of cass_cluster_set_num_threads_io:

• By default use global Tokio runtime. If cass_cluster_set_num_threads_io was called, create cluster-specific runtime with given amount of threads.
• Always use cluster-specific runtime, cass_cluster_set_num_threads_io configures its threads.

I'm fine with both of them.