Panic on control buffer overflow

[haata]

• When writing larger interface descriptors it's possible to overflow
  the buffer (even on LS/FS USB 2.0)
• Cleanup get_descriptor and accept_writer to forward the error
• Then unwrap() it inside get_descriptor
  • unwrap() will panic regardless of the logging mechanism and give a
    useful error message (e.g. defmt):
    ERROR panicked at 'called Result::unwrap() on an Err value: BufferOverflow'
  • We want to panic as continuing usually halts/suspends the USB
    device which will usually retry enumeration a few times until the
    host gives up
  • This is most common during initial enumeration, but it's also
    possible when requesting debug descriptors (e.g. lsusb)
• Ideally we should return some sort of error that recommends enabling
  the control-buffer-256 feature but this isn't straightforward with the
  current design

[ryan-summers]

Thanks for the fix PR!

Can you please add a CHANGELOG entry for the fix?

It would also be helpful to file an issue to describe the defect that you're seeing. After reviewing the code, I think I understand, but it wasn't immediately clear to me from the start.

In any case, this one wasn't too hard to figure out, but it would be helpful for others looking for fixes and/or looking up similar errors in the future :)

[ryan-summers]

I don't think unwrap()ing the result here is the best approach. This will inject fmt bloat into applications for people that may not be able to pay the memory overhead.

We should likely bubble the error up instead and let the user handle the Result

[haata]

👍