libusb: dequeue next transfer on completion to prevent stallsstable/14

The transfer proxy callbacks (bulk/interrupt, control, isochronous)
only called libusb10_submit_transfer_sub() in the START path to
pipeline the second kernel transfer slot. On completion or error,
no attempt was made to dequeue the next pending transfer from
tr_head onto the now-free slot.

When more than two async transfers were submitted on the same
endpoint, the third (and subsequent) transfers would remain stuck
on tr_head indefinitely, since no completion ever triggered their
submission. This caused a protocol-level deadlock in applications
like adb that submit header + payload + zero-length terminator as
three separate bulk transfers in sequence.

Fix by calling libusb10_submit_transfer_sub() after every
libusb10_complete_transfer() in all three proxy callbacks.

MFC After:	2 weeks
Reviewed by:	adrian
Differential Revision:	https://reviews.freebsd.org/D55289

(cherry picked from commit 38c18332642500fdfe075a82f88e033f6673a53f)

0 files changed, 0 insertions, 0 deletions