Deserialization refactor: introduce new deserialization traits

[wprzytula]

Fixes #961
Fixes #963

Huge credits to @piodul for creating most of the new deserialization framework!

The new traits

This PR introduces the new deserialization traits, DeserializeValue and DeserializeRow, which are going to replace FromCqlVal and FromRow, respectively.

If a type implements DeserializeValue<'f>, this means that it can take a buffer of lifetime 'f and deserialize itself, treating the contents of the buffer as a CQL value. Analogously, DeserializeRow<'f> allows for deserialization of types that are supposed to represent a whole row returned in the results.

Deserialization is now split into two phases: type checking and actual deserialization. Both traits have two methods: type_check and deserialize. The idea behind this is to validate the column types of the response only once, after the response is received. The deserialize method is then called for each row/value to perform the actual parsing: that method is allowed to assume that type_check was called and may skip some type checking for performance (although it cannot use that assumption to perform unsafe operations, it is not an unsafe method).

The previous framework only supported deserialization of types that exclusively own their data, for example String or Vec<u8>. However, the new framework allows for types that borrow or co-own the frame buffer:
- Types that borrow the buffer are &'f str and &'f [u8]. They just point to the raw data from the serialized response. Rust's lifetime system makes sure that the the user doesn't deallocate the serialized response until using the deserialized types that point to the buffer are dropped. Apart from the aforementioned types, a bunch of iterator types have been introduced that allow consuming collections without allocations.
- Serialized frame is represented with bytes::Bytes. It is possible to create a subslice (also of type Bytes) that keep the original alive. The type being deserialized can obtain access to such subslice. Like in the case of e.g. &str vs. String, keeping Bytes allows to avoid an allocation, but it is also easier to handle as deserialized type doesn't have to be bound by any lifetime. It important to be careful when handling such types as they keep whole serialized frame alive, even if they only point to a subslice. This can lead to a space leak and more memory being used than necessary.

Implementation of the new traits for all supported types

All the previously supported types (i.e. those that could be deserialized using the old framework) are supported now as well.
There is only one exception: CQL List is no longer deserializable into a set (HashSet or BTreeSet), because such conversion could be lossy, which is an unwanted property for deserialization.

Errors

The error framework is analogous to one used in the serialization framework: DeserializationError is added that resembles SerializationError and is type-erased as well.

As the new deserialization framework has separate type_check() and deserialize() function (contrary to the serialization framework, which has only one serialize() method), it makes sense for them to return distinct errors.
That's why a new TypeCheckError is added, too, which is type-erased as well.

Testing

• All new types are unit tested.
• Additionally, a decent test suite is added to verify compatibility of the old and the new framework. As in a later commit the old framework (deser_cql_value) is refactored to use the new one, the compatibility tests are then removed.
• Another test suite is added to check that serialization composed with deserialization yields identity.
• New errors are tested, too, although not exhaustively. I'd prefer not to bog down too much in testing them thoroughly.

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 detected some API incompatibilities in this PR.
Checked commit: 30d5149

See the following report for details:

cargo semver-checks output

./scripts/semver-checks.sh --baseline-rev 3d3c35392250c98ee9ad5c0d23e71b9ec42892ca
+ cargo semver-checks -p scylla -p scylla-cql --baseline-rev 3d3c35392250c98ee9ad5c0d23e71b9ec42892ca
     Cloning 3d3c35392250c98ee9ad5c0d23e71b9ec42892ca
     Parsing scylla v0.13.0 (current)
      Parsed [  23.587s] (current)
     Parsing scylla v0.13.0 (baseline)
      Parsed [  21.139s] (baseline)
    Checking scylla v0.13.0 -> v0.13.0 (no change)
     Checked [   0.523s] 72 checks; 72 passed, 0 unnecessary
    Finished [  45.300s] scylla
     Parsing scylla-cql v0.2.0 (current)
      Parsed [   9.810s] (current)
     Parsing scylla-cql v0.2.0 (baseline)
      Parsed [   9.627s] (baseline)
    Checking scylla-cql v0.2.0 -> v0.2.0 (no change)
     Checked [   0.297s] 72 checks; 71 passed, 1 failed, 0 unnecessary

--- failure enum_variant_added: enum variant added on exhaustive enum ---

Description:
A publicly-visible enum without #[non_exhaustive] has a new variant.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#enum-variant-new
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.31.0/src/lints/enum_variant_added.ron

Failed in:
  variant ParseError:DeserializationError in /home/runner/work/scylla-rust-driver/scylla-rust-driver/scylla-cql/src/frame/frame_errors.rs:43
     Summary semver requires new major version: 1 major and 0 minor checks failed
    Finished [  19.775s] scylla-cql
make: *** [Makefile:61: semver-rev] Error 1

[wprzytula]

v2:

• addressed most review comments (though DeserializeCql -> DeserializeValue rename has not yet been done),
• set up and used an error framework similar to that used in serialization.

While reviewing, please pay attention to the error types used, especially to the use of GenericParseError variant (which I hate, but before errors refactor I can do little about this).

[muzarski]

Additional question: do we want to expose all of the iterator types to the users? I'm aware that UdtIterator might be useful to implement deserialization for custom user types. What about other iterators such as ListLikeIterator or MapIterator? Do you see any reason for exposing these?

[wprzytula]

Additional question: do we want to expose all of the iterator types to the users? I'm aware that UdtIterator might be useful to implement deserialization for custom user types. What about other iterators such as ListLikeIterator or MapIterator? Do you see any reason for exposing these?

1. exposing them might be useful for cpp-rust-driver (but in this aspect it's better to start with private visilibity and make it public only if really needed there),
2. it's not scylla-cql crate that should control visibility of the exports; it's scylla crate's responsibility to organise exports, just like you've recently done wrt some other exports from scylla-cql. Ideally, only leaf items (e.g. structs, consts, enums, etc.) are re-exported by scylla from scylla-cql, no node items (i.e. modules) - this gives the finest control over visibility.

[wprzytula]

Rebased on main.

[wprzytula]

v6.3:

• changed UdtIterator Item a bit (will be useful for derive macros in the follow up)
• added test cases that checks errors when collections are attempted to be deserialized from null.