a message of `msize' len is valid, we just need to make sure to _not_ overflow it.

except for Twrite, all other requests are passed via a single imsg. We don't handle "jumbo" request for anything outside Twrite, nor it does make sense actually, so let's drop it. (well, for Twstat an argument can be made, maybe)

Until now I've been using a single imsg to handle each messages and the imsg framework has a limit of around 16K for message. For almost all requests, this is fine. Except for Twrite and Tread. This is an attempt to make Twrite handle bigger buffers. The listener process just looks at how big a request is and split it up in multiple messages and the client process tries to remember the fid, position and missing data to continue the write. This means that a single Twrite can be split up in multiple write(2)s.

twstat was truncating out the user mode bits. Found the hard way by cage.

Select only the lower two and set the correct bit for directory entries. While the lower two bytes seems to behave just as on UNIX, the upper ones don't (at least on OpenBSD.)

9front uses aname "" during Tattach, at least with 9fs without special arguments, so convert it to our current representation.