Using rustc-serialize

[aplanas]

The crate rspotify and rspotify-model are depending on chrono, and the Cargo.toml of both craters are enabling the optional rustc-serialize feature of chrono, dragging it into the dependency tree. Seems that rustc-serialize eventually rustc will refuse to compile it:

warning: the following packages contain code that will be rejected by a future version of Rust: rustc-serialize v0.3.24
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`

The package `rustc-serialize v0.3.24` currently triggers the following future incompatibility lints:
> warning: impl method assumes more implied bounds than the corresponding trait method
>     --> /home/aplanas/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-serialize-0.3.24/src/serialize.rs:1155:41
>      |
> 1155 |     fn decode<D: Decoder>(d: &mut D) -> Result<Cow<'static, T>, D::Error> {
>      |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this type to make the impl signature compatible: `Result<Cow<'a, T>, <D as serialize::Decoder>::Error>`
>      |
>      = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>      = note: for more information, see issue #105572 <https://github.com/rust-lang/rust/issues/105572>
>      = note: `#[allow(implied_bounds_entailment)]` on by default
>

IIUC this means this crate will not be possible to compile in the future.

Maybe the fix is to replace https://github.com/ramsayleung/rspotify/blob/master/Cargo.toml#L36 with

chrono = { version = "0.4.19", features = ["serde"] }

And a similar change in rspotify-model Cargo.toml

[Kurtsley]

It looks like this can be done with absolutely no adverse effects. Nothing needs to be re-written.