Add DecodeAsType backed by Visitor impls for standard types.

[jsdw]

Part of a series:

• scale-encode: new crate to handle encoding using type info.
• !scale-decode: handle decoding using type info.
• scale-value: update Value type to use scale-encode/decode.
• subxt: Start taking advantage of these in Subxt.

This PR:

• Makes the Visitor trait suport zero-copy decoding from SCALE bytes, and generally overhauls it to be simpler/more powerful to write impls.
• Adds an IntoVisitor trait which describes how you can obtain a visitor impl for some type.
• Adds a DecodeAsType trait which is implemented by default when the above is true (and the visitor error can convert into a crate::Error). This roughly mirrors EncodeAsType from scale-encode.
• Adds a DecodeAsFields trait which is implemented for all composite/tuple types by default and allows a list of scale_info::Fields to be used to decode some value into a concrete type (this roughly mirrors EncodeAsFields from the scale-encode crate).
• Adds a load of impls for common types
• Adds a DecodeAsType proc macro that implements the necessary things on custom structs and enums.
• Does various tidyup.

Closes #8

[lexnv]

👍 LGTM! Amazing change!

[niklasad1]

I don't really understand why you need a LinkedList here, isn't VecDeque sufficient?

It seems like it's just need push_front and iterator over it?

[jsdw]

I think you're right! I wrote the linkedlist back when I was passing context in, and so needed to be able to cheaply clone and add items to the front. But now, since it's just appended to on the way back, you're totally right and a simple Vec should do the trick!

[jsdw]

Got rid of LinkedList and replaced with a Vec; I'll do the same in scale-encode too!

[jsdw]

paritytech/scale-encode#5

[niklasad1]

would interesting with some benchmarks on this compared to Vec and SmallVec :)

[jsdw]

Hehe yeah; I just wrote the minimum bit really to avoid another dependency; the hope is that it will never need to allocate unless something crazy comes up!

[lexnv]

If we'd want to squeeze every bit of performance out of it, the current implementation could allocate twice when moving the vector from the stack to the heap.

// First allocation goes here
                    let mut v = items[..].to_vec();
                    
// Potential allocation for extending the vector + a memcpy
                    v.push(item);
                    
                    self.inner = StackVecInner::Heap { items: v };

We could optimize those similar to:

            let mut v = Vec::with_capacity(N + 1);
            // SAFETY: we allocate the appropriate number of elements
            unsafe {
                items.as_ptr().copy_to_nonoverlapping(v.as_mut_ptr(), N);
                v.set_len(N);
                // We could probably do some pointer magic to call `set_len` only once
                v.push(item);
            }
            self.inner = StackVecInner::Heap { items: v };

Please feel free to ignore this :D Seems that may not be the most common case

[jsdw]

I'm hoping it'll never happen; only if a compact encoded type is nested in a crazy number of new type wrappers :) so yeah it's no biggie, but nice one!

[niklasad1]

💪