condvar_wait() wrongly dropped the condvar's internal lock too early,
and accessed wr->t outside the lock, meaning that a concurrent wake()
could race with it. This bug was exposed in one of the pipe() tests.

This patch fixes this bug, by holding the internal lock throughout
the execution of condvar_wait(), dropping it temporarily only while
waiting.

add simple select() implementation on top of poll(), been tested by
running netperf/iperf3 which is using select() for waiting for reads
and setting timeouts.

haven't been thourougly tested.

also, it's better to call poll_wake() with both POLLIN/OUT and
POLLRDNORM/POLLWRNORM, just to be on the safe side. seen a few
references in the jdk.

We need to ifdef out more unused code to not make gcc complain.

This patch adds pipe(). The pipes are built using the same FIFO implementation,
"af_local_buffer", as used by the existing unix-domain socketpair
implementation - while the socket-pair used two of these buffers, a pipe
uses one.

This implementation deviates from traditional POSIX pipe behavior in two
ways that we should fix in followup-patches:

1. SIGPIPE is not supported: A write to a pipe whose read end is closed
   will always return EPIPE, and not generate a SIGPIPE signal.
   Programs that rely on SIGPIPE will break, but SIGPIPE is completely out
   of fashion, and normally ignored.

2. Unix-style "atomic writes" are not obeyed. A write(), even if smaller
   than PIPE_BUF (=4096 on Linux, whose ABI we're emulating), may partially
   succeed if the pipe's buffer is nearly full. Only a write() of a single
   byte is guaranteed to be atomic.

   We hope that Java doesn't rely on multi-byte write() atomicity
   (single-byte writes are enough for waking poll, for example), and users
   of Java's "Pipe" class definitely can't (as Java is not Posix-only),
   so we hope this will not cause problems. Fixing this issue (which is easy)
   is left as a TODO in the code.

Additionally, this patch marks with a FIXME (but doesn't fix) a serious
bug in the code's iovec handling, so writev() and readv() are expected
not to work in this version of pipe() - and also on the existing socketpair.

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.

Previous commit broke the build, because I forgot to commit a file.

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).

If poll() was waiting on a file descriptor from socketpair_af_local, we
would never wake it up, and an example of this is the failure in a
recently committed fix to tst-af-local.cc.

The problem is that when one writes to one end of the socket, we need to
call wake_poll() on the other end of the socket, so we need to remember
which "struct file *" is attached to each end of the af_local_buffer objects.

What I did is what I thought the most elegant solution is:

Rather than having "sender" and "receiver" of af_local_buffer booleans,
they are now "struct file *". I added new functions, attach_sender(f) and
attach_receiver(f), which set the file* we'll need to notify for each
end; These functions are analogous to functions detach_sender, detach_receiver
that we already had.

After each interesting event - read, write, close, etc - we notify the
appropriate file*, using poll_wake.

attach_sender(f) and attach_receiver(f) is called by af_local_init(f) - which
used to be empty and now does something. Note how af_local_init(f) only
does send->attach_sender(f) and receive->attach_receiver(f), but doesn't
touch the two others (send->attach_receiver, receive->attach_sender) -
these other two are set when the second file descriptor, with the send
and receive fifos in reversed roles, is initialized with its af_local_init.

After this fix, the new af_local_test works correctly.

The tst-af-local.so test supposedly tested a waiting poll() on a
unix-domain socketpair, but unfortunately the test was incorrect - the
writer thread usually (even always) manged to write to the socket before
poll() started, so poll() never actually had to wait and always returned
immediately.

But it turns out, when we really do need to wait, there *is* a bug:
poll() doesn't wake up when input arrives. So this patch fixes the *test*
to demonstrate the bug. After this fix, the tst-af-local.so test now fails.
I'll fix the bug, to make the test pass again, in a followup patch.

Don't abort on an unimplemented sysconf parameter. One of the documented
functions of sysconf(3) is to "test ... whether certain options are
supported", so programs are free to test for features we don't support
yet, and we're supposed to return -1 with errno set to EINVAL.

For example, Boost tested _SC_THREAD_SAFE_FUNCTIONS which we didn't
support. It would have been fine if we set EINVAL (it would switch
from *_r functions to the non-reenatrant ones) - but it wasn't fine
that we abort()ed because of this test :-)

To be on the safe side, this patch still prints a message if we see an
unknown sysconf - in case in the future we'll come across a new one we
must treat. But eventually, the message should go away too.

Implement the _SC_THREAD_SAFE_FUNCTIONS sysconf, returning 1.

_SC_THREAD_SAFE_FUNCTIONS is defined in Posix 1003.1c ("posix threads"),
and is supposed to return 1 if the thread-safe functions option is
supported (*_r() functions). Since we do implement those, we should return
1 for this sysconf.

Boost's system library uses this sysconf, and if it sees it is not
available, restorts to the _r()-less variants, for no good reason.

This patch implements readdir64, as an alias to readdir. We can do this,
because on 64-bit Linux, even the ordinary struct dirent uses 64-bit
sizes, so the structures are identical.

The reason we didn't miss this function earlier is that reasonable
applications prefer to use readdir64_r, not readdir64. Because Boost
filesystem library thought we don't have the former (see next patch
for fixing this), it used the latter.

Say we also implement librt.so.1. This is required, for example, by the
Boost libraries (e.g., libboost_system-mt.so.1.50.0). The librt library
isn't actually a separate library on modern Linux - rather all its
traditional functions are now in glibc, and "librt" is merely a filter
on glibc. So no reason not to say we support librt too.

Not to mention that we already implement a bunch of functions that
traditionally resided in librt (nanosleep, sched_yield, sem_*, etc.

Added a simple readdir() and readdir_r() test.
The test is successful - it turns out readdir() had no bug, and the bug
was in mkbootfs.py, but since I already wrote the test I guess might as
well add it.