Simplify via zerocopy::FromZeros::new_box_zeroed

[Leon Schuermann (lschuermann)]

The existing implementation of box_new_zeroed was unnecessarily complex. This PR simplifies it.

[Leon Schuermann (lschuermann)]

I see that the ratchet::ratchet_maybe_uninit test fails, which I assume is just a guard to ensure one is not inadvertently adding a new unsafe transmute? Either way, I think this is cleaner and more idiomatic; should I go ahead and add a path prefix to the ratchet test accordingly?

[Jay Bosamiya (Microsoft) (jaybosamiya-ms)]

Overall seems good to me, thanks Leon! Minor stylistic thing: prefer SAFETY: ... comment rather than # Safety\n\n... comment when discharging a safety obligation.

Also, fwiw, maybe we should use FromZeros::new_box_zeroed instead of the current body? Might need to tweak Cargo.toml to pull in the alloc feature, but since we're depending on alloc anyways, that's not an issue. Thoughts?

If we do not use the new_box_zeroed, then yes, we'd need to update the ratchet for this, thanks for confirming.

[Leon Schuermann (lschuermann)]

Agreed, new_box_zeroed seems strictly better. Enabling alloc on zerocopy sounds like the right call and could enable a bunch more cleanups. In that case, it's probably best to get #817 over the finish line first and do the cleanup inline on top of that merged result.

[Leon Schuermann (lschuermann)]

Jay Bosamiya (Microsoft) (@jaybosamiya-ms) Finally got around to this after #817 merged, sorry for the delay. Switched to zerocopy's function (which does force us to handle an alloc error that appears to be distinct from the other errors in that function's return type, so I added one).

[Jay Bosamiya (Microsoft) (jaybosamiya-ms)]

LGTM, thanks for the cleanup Leon! I'll clean up the PR description before merging, since the merge queue uses it as the commit message