In flush_tlb() avoid the ipi and synchronization protocol if there's just one
cpu. We still a tiny amount of memory and a vector for this purpose even if
there's just one cpu (if it really bothers anyone, I can fix this too...).

Happens in some corner cases.

The current implementation returns 1, leading the JRE to optimize for
a uniprocessor host.  Unfortunately those optimizations are unsafe on SMP,
leading to hangs.

Fix by returning the real number of processors.

Sorry, also forgot to commit this earlier!
Add a new function to send API to all processors accept this one.

Previously, on mmap()/munmap()/mprotect() we only flushed the current
processor's TLB. This was wrong, and this patch adds a test in tst-mmap.cc
to check this case - one thread writes to memory successfully, a second
thread on a second cpu mprotects() this memory, and the first thread then
writes - and wrongfully succeeds because the TLB was not flushed on its CPU.

Fixed the bug by having tlb_flush() send an IPI to all processors (but
itself) telling them to flush their TLB. The call to tlb_flush() doesn't
return until all processors flush their TLB. All of this is slow, but
necessary for correctness...

The new test in tst-mmap.cc now passes (i.e., the second write fails as
expected).

Unfortunately, this doesn't fix any of the systemic bugs we noticed earlier,
but will surely have caused some bug in the future if we didn't fix it.

The page fault handler used to abort() if the current thread wasn't a
pthread thread - instead of calling the handler. I don't see any reason
to do this - and it ruined my ability to catch desired write faults in
the two-thread (and two cpu) mprotect() tests.

Previously, we had the option to create a pinned thread, but it always
runs on the same CPU as the current thread, which is kind of odd. Changed
the boolean attribute "pinned" to a cpu* attribute specifying the cpu to
pin to.

Example code to run a start a new thread pinned on cpu 1:
new sched::thread([&]{...}, sched::thread::attr(sched::cpus[1]));

I need this feature to test the cross-CPU TLB flushing feature - I need
to be able to run two threads on two different CPUs.

Changed mmap tests from tst-hub include to a separate .so, making it easier to
run separately. Also removed a bunch of redundant dependencies from build.mak.

Added build ("make") framework for compiling Java code we want to run in
OSv (in/with the Java payload), as well as JNI, i.e., OSv-specific C code
we want to run from the above Java code.

The Java source files in java/src/ are now all compiled during build
(see java/build.xml for the Ant file doing this compilation) and the
result is one JAR, build/$mode/java/cloudius.jar (/cloudius.jar in bootfs).
We can easily change build.xml to create more than one if we want.

As an example of JNI, I used the not-working-yet balloon feature.
java/src/com/cloudius/balloon/Balloon.java is the class
com.cloudius.balloon.Balloon which is supposed to have one "native"
(implemented in C) function giveup(). This function's implementation is
in java/jni/balloon.c. We get this file to compile to balloon.so (put
in /usr/lib/jni in the bootfs) by adding java/jni/balloon.so to the
"jni" list in build.mak.

If you don't know how write the ugly function signature as seen in
java/jni/balloon.c, you can run "javah com.cloudius.balloon.Balloon"
to build the empty functions needed for implementing the native functions
defined in the above class.

While I implemented TCSETS ioctl, TCGETS used to be a no-op. This patch
implements it (which is trivial). TGETS is need because the standard
idiom for programs which switch to raw mode is to use TCGETS to save the
original mode, then use TCSETS, and when exiting restore the original mode.

Also used <sys/ioctl.h> definitions (from the host...) instead of the ugly
ioctl numbers.

run a javascript CLI by default on boot.

1. implements trivial versions of ls, cat, cd, pwd, help
2. needs raw mode from the console, handles backspace and tab
3. provide autocomplete support

the javascript CLI owns echo and line editing discipline and needs
raw mode from the console.

needed by the javascript console for ls support

1. pthread_join should allow retval=NULL, in which case the return value is
ignored. We therefore need to use void**, not void*&, otherwise passing NULL
causes pthread_join to crash in a strange way.

2. pthread_join forgot to delete the object allocated in pthread_create

mmap/munmap and its cousins mmu::map_*() used to leak the 48-byte "vma"
object, twice. The idea to separate reserve() and map() was a good one,
but it was implemented incorrectly causing a vma object to be allocated
twice per mmap, and both of them were leaked when evacuate() didn't free
them.

So switched to a simpler implementation, where the "vma" object is internal
to mmu.cc, and not used by any of the callers; The struct vma is now properly
allocated only once per mmap(), and freed on munmap().

We used rbtree::insert_unique(), which only inserts if the value if unique.
But uniqueness is defined in terms of the ordering function, which compares
vruntime, not object identity.  The result is that if another thread was
queued with exactly the same vruntime, then the new thread is not queued.

Fix by using rbtree:insert_equal(), which inserts unconditionally.

Fixes the callout unit test.

creates 2 threads, a client and a server that perform the tcp echo service,
complete 400 cycles of {accept(),read(),write(),close()} on the server
and {socket(),connect(),write(),read(),close()} in the client.

1. fix many races
2. use a mutex to protect access to callout data structure
3. delete callout->c_state and use the original callout->c-flags
   also update CALLOUT_PENDING and CALLOUT_ACTIVE accordingly.
4. support correct behaviour for callout_pending(), callout_active() and
   callout_deactivate()
5. implement a mutex version: callout_init_mtx() used by tcp syncache
6. add debug prints

these are used by TCP.

connect() fails due to these missing lines.

log lines weren't reaching the console in a synchronized way

previousely, the len argument weren't handled correctly, it should be returned
to the user and the sockaddr salen should be initialized with the api when
possible.

the rwlock stub were written before our mutex were recursive, now
we just don't need any extra recursive layer in rwlock