Remove GenericArray

[kevinheavey]

This branches off #2054 so that needs to be merged first

Problem

generic-array is an annoying dependency that is quite avoidable. We can avoid it by hand rolling the serde impls for Signature, or by using the serde_with or serde-big-array crates.

This PR hand rolls the serde impls by closely mimicking what generic-array does (but without the generic stuff). The advantage of this approach is that we should have the same behaviour and performance as before. The disadvantage of this approach is I cargo culted it somewhat so it would be good for someone to look over the unsafe code.

It's possible that serde_with or serde-big-array are better solutions but I haven't investigated the performance or if they differ in any edge cases. I did try serde_bytes and saw that it serialized differently when using short_vec, so the serialization is not trivial.

Summary of Changes

• Replace GenericArray<u8, U64> with [u8; 64]
• Hand roll serde impls based on the serde code in generic-array
• Remove generic-array everywhere else as it is now unused

[kevinheavey]

This is the serde code from the generic-array crate that I've ported over: https://github.com/fizyk20/generic-array/blob/master/src/impl_serde.rs

[juchiast]

The disadvantage of this approach is I cargo culted it somewhat so it would be good for someone to look over the unsafe code

The unsafe code can be replaced with std::array::try_from_fn, which is in nightly because it use the Residual trait, we could copy std code and make it use Result<T, E> for a safer version.

[joncinque]

Sorry for the long wait on this, I wanted to take time to properly test the implementation. Since serialization is simple, I setup a simple bench to see how deserialization performs:

#![feature(test)]
extern crate test;

use {
    solana_signature::Signature,
    std::hint::black_box,
    test::Bencher
};

#[bench]
fn bench(b: &mut Bencher) {
    let sig_bytes: [u8; 64] = [
        01, 02, 03, 04, 05, 06, 07, 08, 09, 10,
        11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
        21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
        31, 32,
        01, 02, 03, 04, 05, 06, 07, 08, 09, 10,
        11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
        21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
        31, 32,
    ];
    let mut reverse_sig_bytes = sig_bytes.clone();
    reverse_sig_bytes.reverse();
    b.iter(|| {
        for _ in 0..100_000 {
            black_box(bincode::deserialize::<Signature>(&sig_bytes).unwrap());
            black_box(bincode::deserialize::<Signature>(&reverse_sig_bytes).unwrap());
        }
    });
}

This PR does exactly the same performance as master:

test bench ... bench:     316,893.35 ns/iter (+/- 665.45)

I also lifted the exact implementation from serde for its arrays, and it got way worse:

test bench ... bench:  27,246,217.40 ns/iter (+/- 765,600.49)

I also tried serde_big_array:

test bench ... bench:     316,795.35 ns/iter (+/- 523.79)

Considering it provides the same performance as all the hand-rolled code, how about we use serde-big-array? I tested build times with this PR and with serde-big-array, and I noticed 0 impact on my machine.

[joncinque]

Looks great, thanks!

[mergify]

automerge label removed due to a CI failure