Add support for custom CQL types

[psarna]

CQL v4 spec mentions that aside from native types, it's also possible to return a custom type. Excerpt from the spec: https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v4.spec

The option for <type> is either a native
          type (see below), in which case the option has no value, or a
          'custom' type, in which case the value is a [string] representing
          the fully qualified class name of the type represented. Valid option
          ids are:
            0x0000    Custom: the value is a [string], see above.
            0x0001    Ascii
            0x0002    Bigint
            0x0003    Blob

We currently don't support any custom types, but given the problem described in #363 where Cassandra returns duration as a custom type, we should add a mechanism for implementing such support.

[piodul]

In #363, we gained a (hardcoded) support for deserializing org.apache.cassandra.db.marshal.DurationType as Duration - this is how Cassandra serializes the Duration type in the v4 of the CQL protocol. Other custom types still aren't supported.

[avelanarius]

Should we close this issue as not planned?

• We have already covered the org.apache.cassandra.db.marshal.DurationType use case
• I don't think there are future plans to use custom types in ScyllaDB
• Custom types are deprecated in Cassandra:

  Custom types exists mostly for backward compatibility purposes and their usage is discouraged. Their usage is complex, not user friendly and the other provided types, particularly user-defined types, should almost always be enough.

[piodul]

Yes, given your arguments @avelanarius I think it makes sense to close. Serializing/deserializing such types should be possible if somebody provides custom implementations of the relevant traits (for deserialization, it will require #462). As they are deprecated, we don't need to care about them in CqlValue.

@Lorak-mmk what do you think?

[Lorak-mmk]

I think (but am not sure) that it is currently possible to serialize such values (by manually implementing SerializeCql) and so insert them into database.
Regarding deserialization, in the examples directory we have custom_deserialization.rs example and I think it should nearly allow selecting such a type - I suspect the only thing missing is adding a Custom variant to CqlValue.
So making it possible (but not easy) to operate on custom type should be a pretty simple task. But given arguments from @avelanarius that is probably unnecessary work and we should close this issue. This is also an issue opened by us - are we aware of any users actually wanting this feature?

One thing to note is that it won't be possible to implement this after 1.0 (without releasing 2.0) unless we mark CqlValue as non-exhaustive.

[wprzytula]

But given arguments from @avelanarius that is probably unnecessary work and we should close this issue.

I'm convinced fully, Custom is a pure legacy, UDT is the present and the future.