Array reads leak resources owned by successfully constructed elements if a subsequent element read fails

[wildbook]

My bad for not initially catching this when looking over the fix in #254. I just looked over the code again while showing it to a friend and realized that Drop isn't called for successfully read elements if a subsequent element read fails.

It's not UB to not call Drop (or std::mem::forget would need to be unsafe), so this isn't as critical as #263, but I imagine it's still desirable to call it and free potentially allocated resources when possible.

---

Minimal example:

use deku::{DekuContainerRead, DekuRead};

fn main() {
    println!("{:?}", Foo::from_bytes((&[1, 2], 0)));
}

#[derive(DekuRead, Debug)]
struct Foo([Bar; 3]);

#[derive(Debug)]
struct Bar(u8);

impl<'a> DekuRead<'a> for Bar {
    fn read(input: &'a deku::bitvec::BitSlice<deku::bitvec::Msb0, u8>, ctx: ())
        -> Result<(&'a deku::bitvec::BitSlice<deku::bitvec::Msb0, u8>, Self), deku::DekuError>
    where
        Self: Sized,
    {
        let (input, value) = u8::read(input, ctx)?;
        // This could allocate memory or otherwise acquire resources that should be freed
        println!("+1");
        Ok((input, Bar(value)))
    }
}

impl Drop for Bar {
    fn drop(&mut self) {
        // If N elements are read and the N+1th element fails, this is never called
        println!("-1: {:x?}", self);
    }
}

+1
+1
Err(Incomplete(NeedSize { bits: 8 }))

---

I'm guessing the most common case this affects is something like this:

fn main() {
    // There's not enough input data so the second `Bar::read` will fail, but only after
    // allocating memory during the first `Bar::read` call. Since existing elements aren't
    // dropped on failure we're leaking the first `Bar` instance's allocated resources, in this
    // case the Vec's backing memory.
    println!("{:?}", Foo::from_bytes((&[1], 0)));
}

#[derive(DekuRead, Debug)]
struct Foo([Bar; 2]);

#[derive(DekuRead, Debug)]
struct Bar {
    #[deku(count = "1")]
    vec: Vec<u8>,
    // ...
}

[wcampbell0x2a]

@wildbook can you confirm the fixes merged with #317?

[wildbook]

I can confirm that fix looks proper to me. Thanks!