Sprinkle #[inline] across the library

[wprzytula]

What's done

I went through all the code in our library and added #[inline] attribute to pub functions that are short enough to make sense to be inlined.

Note that here are no changes to scylla-macros, because they only emit functions that are arbitrarily large (depending on the number of fields of a custom struct passed to the macros).

Results

These are the changes in the binary size (left = after, right = before):

❯ diff -y <(ls target/release/deps/integration-67e7ceb0bf5d0a39 --size) <(ls target/release-non-inline/deps/integration-67e7ceb0bf5d0a39 --size)
25072 target/release/deps/integration-67e7ceb0bf5d0a39	      |	25032 target/release-non-inline/deps/integration-67e7ceb0bf5d

❯ diff -y <(ls target/release/ --size) <(ls target/release-non-inline/ --size)
total 22016						      |	total 21916
   0 build							   0 build
   0 deps							   0 deps
   0 examples							   0 examples
   0 incremental						   0 incremental
   4 libscylla_cql.d						   4 libscylla_cql.d
7820 libscylla_cql.rlib					      |	7752 libscylla_cql.rlib
   8 libscylla.d						   8 libscylla.d
   4 libscylla_macros.d						   4 libscylla_macros.d
4120 libscylla_macros.so					4120 libscylla_macros.so
   4 libscylla_proxy.d						   4 libscylla_proxy.d
1256 libscylla_proxy.rlib					1256 libscylla_proxy.rlib
8800 libscylla.rlib					      |	8768 libscylla.rlib

Conclusion

As you can see, there is a slight increase in the binary size of both libraries, as well as the integration test suite.
This is something that I'd expect if my changes do affect the compiler's inlining decisions.

Fixes: #949

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: 5ff333a

[Copilot]

Copilot reviewed 46 out of 46 changed files in this pull request and generated no comments.

[Lorak-mmk]

Please read:
rust-lang/hashbrown#119
https://nnethercote.github.io/perf-book/inlining.html
https://std-dev-guide.rust-lang.org/policy/inline.html

You did not provide any benchmarks suggesting that this improves performance. You did not provide comparisions of release compile times.
We, as far as I know, have absolutely no reason to believe that Rust Driver has performance issues because of inlining heuristics in LLVM (which are afaik quite good).
I see no point of adding some voodoo "performance improvements" without having a tangible reason to, and evaluating the downsides.