Simplify fixed decoding in derive macro

[paulhauner]

Simplifies how we decode a fixed-length struct using the derive macro. My reasoning is:

• I find this implementation simpler to read.
• I also understands it avoids one checked_add and one bounds check per decoding, which is unlikely to be impactful but it's a nice-to-have.

Safety argument

It's clear that slice will always be exactly #ssz_fixed_len.

There will be no trailing bytes after all the split_ats due to the bytes.len() != <Self as ssz::Decode>::ssz_fixed_len() at the start of the encoding. This assumes the integrity of Self::ssz_fixed_len, but that's an existing and fair assumption.

We will never panic during split_at if we uphold the assumption in the previous paragraph.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.50%. Comparing base (576bb81) to head (730dc58).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #40   +/-   ##
=======================================
  Coverage   77.50%   77.50%           
=======================================
  Files          12       12           
  Lines         720      720           
=======================================
  Hits          558      558           
  Misses        162      162           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[michaelsproul]

LGTM, I couldn't spot an issue with this.

Even if the ssz_fixed_len and from_ssz_bytes impls for a type are out of sync, we still won't panic because we return an error from from_ssz_bytes. I agree that the way ssz_fixed_len is calculated as the sum of each field's lengths means that we can split the input bytes into chunks of size T::ssz_fixed_len() wihtout panicking.

[michaelsproul]

I think this change is backwards compatible because it doesn't change the semantics of the generated code