CurrentThread runtime support - fix

[wprzytula]

So far, the implementation of CassFuture caused deadlock when the only thread called cass_future_wait(). This happened because the thread went asleep on a Condvar until the future is resolved, but there were no other executors that would resolve the future. Although a runtime with no worker threads is not recommended for production usage, it is helpful e.g. for debugging (as it makes execution serialised). Therefore, we fix the problem by changing the way the thread waits for the future's result: instead of sleeping while the future is not yet resolved, it calls runtime.block_on(fut), which makes it the executor of that future. This not only fixes the problem, but possibly boosts efficiency. More specifically, it saves a sleep and a wakeup in the case of having a non-empty worker thread pool (the main thread does not wake a worker, falls asleep until the worker thread resolves the future and gets woken up in the end, but instead simply does the work by itself).

To test that the changes did solve the problem, change RUNTIME in lib.rs into a "current thread" variant: from:

pub static ref RUNTIME: Runtime = Runtime::new().unwrap();

into:

pub static ref RUNTIME: Runtime =
        tokio::runtime::Builder::new_current_thread()
                .enable_all()
                .build()
                .unwrap();

Pre-review checklist

• [x] I have split my patch into logically separate commits.
• [x] All commit messages clearly explain what they change and why.
• [x] PR description sums up the changes and reasons why they should be introduced.
• [ ] I have enabled appropriate tests in .github/workflows/build.yml in gtest_filter.
• [ ] I have enabled appropriate tests in .github/workflows/cassandra.yml in gtest_filter.

[wprzytula]

v2: I've fixed the race condition and hardened CassFuture a bit:

• added a compile-time assertion of Send + Sync
• written a smoke test of thread safety