cuse: Fix hang on readv(2) and writev(2) with multiple iovecs

[christos]

Summary

uiomove() leaves an iovec it has just emptied as the current one, so
cuse_client_read() and cuse_client_write() picked it up again on the
next iteration, sent the server a zero-length command, and got zero
bytes back. That left the residual count unchanged, so the loop never
terminated and the call never returned.

Step past empty iovecs at the start of every iteration. This also covers
caller-supplied zero-length iovecs, which hung in the same way

PR: 293489
MFC after: 1 week
Sponsored by: The FreeBSD Foundation

[markj]

This also means that we won't forward actual zero-length iov entries to the server. I don't know why a server would care though.

[kib]

sys/fs/cuse/cuse.c

1683–1684

I would move the read of 'len' before two checks, and use the local for '== 0' and '> CUSE_LENGHT_MAX' comparisons.

1781–1782

Same there.