Additional rkyv support by trying to derive the Archived type as Self where possible

[yongqli]

The current support for rkyv in chrono isn't very useful, because rkyv generates a new type on each invocation of derive(Archive). This new type won't have any traits or methods implemented on it except Deserialize, so it can't be easily used in a zero-copy manner.

However, most chrono types are Copy, which means that rkyv can be configured to use Self for derive(Archive) instead of generating a new one. One downside is that this doesn't work if rkyv is configured to use a specific endianness.

Code can be generic to which specific type rkyv generated for the Archive impl through the use of rkyv::Archived<_>, so chrono can opportunistically generate a different type without breaking code that wants to support different endianness, which is also what rkyv currently does for primitives: https://docs.rs/rkyv/0.7.39/src/rkyv/impls/core/primitive.rs.html#107

[yongqli]

Looks like the test runner tried to enable incompatible features.

[djc]

Okay, that's a good reason this won't work: Cargo features must be additive and should not be mutually exclusive. Otherwise one library depending on Cargo could select one feature, another library selects the other, and the application wanting to use both libraries no longer works. So I don't think this can be merged as is.

[yongqli]

One possibility is to add a feature flag to enable attempting to derive using Self instead of the negative selection as it is now. I can also contact the rkyv author for recommendations and feedback.

[esheppa]

rust-decimal recently resolved a similar issue to this with serde by using #[serde(with = "")] attributes which are enabled by features, which enables multiple users of the same library to serialize differently and additively. Potentially this can be handled on the consumer side by using an equivalent attribute from rkyv?

[pitdicker]

I agree it would be cool if Copy types would not even need a serialize/deserialize step when used with rkyv. And of course this breaks down when not everything uses the native endianness.

Closing for now. But if someone figures out a nice solution in rkyv/rkyv#292 feel free to open a new PR.