Remove tokio version bounds

[rukai]

This is fine now since tokio-rs/tokio#6610 is resolved via becheran/ntest#28 which has now been released in ntest 0.9.3
This PR also bumps the itertools + base64 versions, since they are trivial upgrades

The latest git main branch of scylla-rust-driver fails to build in my project due to the version restriction, these kinds of version restrictions often cause problems like this, so it would be bad for such a version restriction to end up in a release.

Pre-review checklist

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• I added relevant tests for new features and bug fixes.
• All commits compile, pass static checks and pass test.
• PR description sums up the changes and reasons why they should be introduced.
• I have provided docstrings for the public items that I want to introduce.
• I have adjusted the documentation in ./docs/source/.
• I added appropriate Fixes: annotations to PR description.

[github-actions]

cargo semver-checks found no API-breaking changes in this PR! 🎉🥳
Checked commit: 568eaf4

[Lorak-mmk]

Thanks for the contribution!
If the issue was resolved via a new version of ntest, then

1. There is no need to bump minimum version of Tokio and we could still use version = "1.34", right?
2. ntest should be bumped to 0.9.3 to avoid problems for people who have lockfiles locally.

(nit) could you split itrertools + base64 update to a separate commit?

[rukai]

The feedback should be addressed now

[Lorak-mmk]

What I meant was to also update ntest in Cargo.toml files - we need to require new version because old version doesn't work with new Tokio.
After you bump those versions I think it's good to go

[rukai]

I've now updated the PR to also update ntest in the Cargo.toml not just in the Cargo.lock.msrv