Add some more OOM-handling Box<[T]> constructor variants

[fitzgen]

Part of #12069

[alexcrichton]

Another possible idea:

• One function to return fn(usize) -> Result<Box<[MaybeUninit<T>]>>
• Another function fn(Iterator<T>, Box<[MaybeUninit<T>]>) -> Result<Box<[T]>>
• Another function for a fallible iterator
• Helper functions combining these together

[fitzgen]

Another possible idea:

• One function to return fn(usize) -> Result<Box<[MaybeUninit<T>]>>

• Another function fn(Iterator<T>, Box<[MaybeUninit<T>]>) -> Result<Box<[T]>>

• Another function for a fallible iterator

• Helper functions combining these together

This is sort of what we have, except we don't expose the second function publicly, just as an implementation detail.

What these proposed functions don't collectively cover, however, is when you have an unknown-length iterator, unless I am misunderstanding.

[fitzgen]

Okay the boxed slice helpers are now implemented on top of our OOM-handling Vec and this PR now depends on #12452 (and therefore also #12448)

[cfallin]

This looks correct to me; I think my main question (in addition to the one naming thought below) is why we need to define an error case TooFewItems. I suppose I'm not seeing the callsite(s) here but naively I would expect, given that we've implemented the shrink_to_fit logic, we could always use that if an iterator returns fewer items than expected; do we have cases where we want to guard against that (reallocation) wastefulness and flag a logic error instead?

[fitzgen]

do we have cases where we want to guard against that (reallocation) wastefulness and flag a logic error instead?

Basically, yes. We have call sites that know the exact length of various things but which also do not have ExactSizeIterators for Reasons.