Support deserializing from borrowed or owned bytes, too

[jsdw]

Support deserializing from bytes, too (see #669).

Closes #669

[ordian]

Could you also bump the patch minor version and update the changelog? Thanks!

[luketchang]

Could we also add support for deserializing from a serde sequence? When substrate chain returns a storage query result for a primitive_types::H256, it comes in the form of a sequence of Primitive::U128 meant to be a Vec<u8>

Roughly the encoding of this structure:

#[derive(Clone, Copy, Serialize, Deserialize)]
pub struct NomadBase {
    /// State
    pub state: NomadState,
    /// Local domain
    pub local_domain: u32,
    /// Committed root
    pub committed_root: H256,
    /// Updater
    pub updater: H160,
}


Value { value: Composite(Named([
  (\"state\", Value { value: Variant(Variant { name: \"Active\", values: Unnamed([]) }), context: TypeId(379) }), 
  
  (\"local_domain\", Value { value: Primitive(U128(0)), context: TypeId(4) }), 
  
  (\"committed_root\", Value { value: Composite(Unnamed([Value { value: Composite(Unnamed([
     Value { value: Primitive(U128(0)), context: TypeId(2) }, 
     Value { value: Primitive(U128(0)), context: TypeId(2) },
     ...
     Value { value: Primitive(U128(0)), context: TypeId(2) }, 
     Value { value: Primitive(U128(0)), context: TypeId(2) }]
  )), context: TypeId(1) }])), context: TypeId(10) }), 

   (\"updater\", Value { value: Composite(Unnamed([Value { value: Composite(Unnamed([
     Value { value: Primitive(U128(0)), context: TypeId(2) }, 
     Value { value: Primitive(U128(0)), context: TypeId(2) },
     ...
     Value { value: Primitive(U128(0)), context: TypeId(2) }, 
     Value { value: Primitive(U128(0)), context: TypeId(2) }
   ])), context: TypeId(77) }])), context: TypeId(76) })])), 

context: TypeId(378) }"}

[jsdw]

I've added support for sequences of bytes, too. That seemed natural and reasonable to support (and indeed it is what scale_value::Values can work best with).

@ordian re version bumping and changelog:

The changelog has an unreleased seciton already and the version isn't bumped from that last change.

Should I either:

1. Bump the version, add my entry and turn "unreleased" into changelog for that version, or
2. Add my entry to "unreleased" and leave it to you or somebody else to bump the version and modify the changelog when they do a release?
3. Other :)

[ordian]

Should I either:

1. Bump the version, add my entry and turn "unreleased" into changelog for that version, or

2. Add my entry to "unreleased" and leave it to you or somebody else to bump the version and modify the changelog when they do a release?

I was suggesting 1, but if you're more comfortable with 2, that works too :)

[jsdw]

I'm happy with 1; happy to just publish the crate too once it's merged but wanted to check that there wasn't any particular release approach/policy to follow if so :)

Edit: Ah I found the CONTRIBUTING.md! One thing to note is that a publish of this crate (impl-serde) would also require a publish and update of a bunch of other crates that depend on older versions of this to actually put it into use, though. Perhaps I'll just publish this one first and can worry about updating the other crates in this repo that depend on it later; wdyt?

[ordian]

Perhaps I'll just publish this one first and can worry about updating the other crates in this repo that depend on it later; wdyt?

Yup, I can take care of the rest. It seems to be another semver-pocalypse which would necessitate a breaking bump for almost all crates.

[jsdw]

I was wondering whether we could have gotten away with a patch bump instead?

I've also been mulling over this and I think I'd like to add a followup PR to accomodate another deserialization woe (basically; the type info for types like H256 indicates that they are some newtype surrounding an array of bytes, and so it would be nice to try and support that, too, in the deserialization, rather than the current stuff which is all good but pretends that we're going straight to an array of bytes.)

[ordian]

I was wondering whether we could have gotten away with a patch bump instead?

I've bumped patch versions on MSRV bump previously and people were not happy about that: #620. The MSRV is not caused by your PR, but an unreleased change.

I understand you want to get this out quickly and easily, but we gotta do it the right way.

I've also been mulling over this and I think I'd like to add a followup PR to accomodate another deserialization woe (basically; the type info for types like H256 indicates that they are some newtype surrounding an array of bytes, and so it would be nice to try and support that, too, in the deserialization, rather than the current stuff which is all good but pretends that we're going straight to an array of bytes.)

It seems the crate hasn't been published, so feel free to submit additional PRs and change the date of the release in the changelog.