We don't have temporary snapshots yet, and we probably never will have processes
that could exit.

It clashes with a macro of the same name in OSv.

OSv isn't ready for this yet.

Previously, we re-implemented "unsupported" file operations (e.g., chmod
for a pipe on which fchmod makes no sense) several times - there was
an implementation only for chmod in kern_descrip.c, used in sys_socket.c,
and af_local.cc had its own. As we add more file descriptor type (e.g.,
create_epoll()) we'll have even more copies of these silly functions, so
let's do it once in fs/unsupported.c - with the fs/unsupported.h header
file.

This also gives us a central place to document (and argue) whether an
unimplemented ioctl() should return ENOTTY or EBADF (I think the former).

getsockname() used to fail because by the time the call chain reached
kern_getsockname() it got addrlen=0. The problem is getsockname1()
which gives it an initialized local variable instead of the given
addrlen.

Most of these layers and copies are redundant, and are only left because
of previous incarnations of the code which had copies from user space -
but we need to at least get the unnecessary copies right ;-)

This allows to remove various #if 0'ed code using vnode_t or znode_t to be
compiled, both in the current headers and future ported code.

BSD and Solaris code likes to pass this identifier for the "kernel" process
to various thread creation routines.  Make our life simpler by providing it
and ignoring it.

the old implementation used threads for dispatching callouts, each callout
owned a thread and it suffered from a race where a callout structure could have
been deleted before the callout thread even begun.

the current implementation is dispatching all callouts in a single callout
dispatcher thread, it maintains an ordered list of callouts to achieve that.

this patch solve a crash with the TCPDownloadFile test, that now proceeds.

the mbuf ext buffer is freed in the dtor, so it should be called before finit.
this is fixing a crash that surfaced by using the conf-memory-debug=1

this haven't caused a real bug, I just noticed it while tracing.
it may be dangerous if in some flow, the stack will not be zeroed