Breaks the build

A straightfoward implementation for SSHD
Supports SCP, SFTP subsystem and a shell through the current JS cli

Broken by 92b6753b.

The test command of the CLI didn't work because Javascript cannot work
with a Java String[] array as if it is a JS array, I was surprised to see
92b6753b and I assumed it works but
apparently the test command got broken.

This patch properly returning a Scriptable object that Javascript
code understands, it acquires a thread specific Rhino Context that
is used to cast the test names to a JS array, and from there the JS
code picks it up.

Pass -X* (and of course also -XX*) options to the JVM.
The -Xmx option is the most useful example.

The JVM options end with the first "-jar" *or* classname, not *and*.
Fix the typo.

Our CLI changes the console's tty mode to raw when doing its line
editing, and back to the original (cooked) mode when running a command.
Obviously, when we're running on a telnet connection we shouldn't touch
the console's mode like the existing code did.

OSV doesn't (at least for now) have ptys, so we can't handle the
telnet connection exactly like we handled the console, and the kernel
can't implement a "cooked" line discipline for us like it implemented on
the console. But we can do a very similar thing in Java instead:

This patch adds a new Java class, "TTY", which has an input and output
stream and an "stty" interface. We have one implementation for the console
(using System.in, System.out and the console's Stty), and a different
implementation, TelnetTTY, for a telnet connection.

This patch does not currently implement a line discipline ("cooked mode")
for this TelnetTTY, so it will always stay in raw mode. This is fine for all
our current uses of the CLI, but if in the future we have commands that read
user input and expect cooked mode (echo, line editing), we'll need to
implement this line discipline.

This patch adds a simple telnet server to OSV, implemented in Java.
One can telnet to the VM's IP address (default port 23) and get a CLI
shell. Multiple concurrent telnet sessions are supported (and the shells
are independent, as expected).

To start the telnet server, simply run the com.cloudius.cli.util.TelnetCLI
class. For example, in the CLI to start a telnet server in the background
use:

	java com.cloudius.cli.util.TelnetCLI &

To start OSV with only a telnet server, try

	sudo scripts/run.py -c1 -nv -m2G -e "java.so -jar
		/java/cli.jar java  com.cloudius.cli.util.TelnetCLI"

(The "cli.jar" in the last example is only needed to set the IP address...)

In the future we can turn the telnet server on by default - but let's
add a password feature first :-) Right now, there's no password requested
when someone telnets in.

The CLI used to assume it was using System.in, System.out (which point
to the console). Now make these parameters. We need this so we can run the
CLI on a telnet connection, and it doesn't send output to the console or try
to read from it.

RhinoCLI relied on a bunch of global Java variables such as _cx and _args.
This was not only ugly, it also prevents us from running multiple instances
of the CLI on the same JVM - e.g., to support multiple telnet connections.

There isn't actually a need for these JVM-wide global variables. At most,
we need to global use variables in the Javascript interpreter (so each
instance of the interpreter would have its own copy).

This patch puts main's arguments in a new global-per-javascript-interpreter
variable "mainargs" instead of the global-for-entire-JVM _args. "_cx" isn't
needed at all: one of uses was to for Java to convert a String[] into the
equivalent Javascript alternative - but Java should just return String[]
and let Javascript worry about handling that (it seems to work just fine
without change). A second use was for returning an exit code, but a more
appropriate methods to do the same thing without global variables exist.

Print useful error messages, instead of cryptic exception traces,
in three cases of "java.so -jar something.jar":

 1. When something.jar doesn't exist
 2. When something.jar exists, but can't be read as a jar (zip) file
 3. When something.jar exists, but doesn't have a "Main-Class" field
    in its manifest.

Starting the CLI and using the run command by specifying it as a run.py argument
didn't work due to a cast problem (run expected NativeArray).

previousely this didn't work:

$ sudo ./scripts/run.py -n -e "java.so -jar /java/cli.jar run tools/netserver-osv -D -4 -f -N" -c2 -m1G

This single Java source file is a full-fledged HTTP 0.9 server.
I wanted to add it to expose the console lock bug (fixed in a separate
patch), and to verify that bind() works correctly (it does).

But additionally, this tiny HTTP server (about 6KB of compressed bytecode)
can be very useful for our CLI - it can be run in the background and let
you view files in the OSV system in your browser, even while another
program is running.

To run Shrew from the CLI, just run

	java com.cloudius.cli.util.Shrew

Which runs the HTTP server in the background (in a separate thread),
letting the user continue to use the CLI. If you add an argument "fg" to
this command, it runs the server in the current thread, never returning.

Currently, the HTTP server is written to browse OSV's root directory
hierarchy: accessing http://192.168.122.100:8080/ from the host shows
you the OSV guest's root directory, and you can decend into more
directories and download individual files.

Exposes tracepoints and counters

The recent change, to add the program name as argv[0] for C code's
main(), make sense for C code, but less for Java code, where main()
normally expects args[0] to be the first argument, not the program name.

So the change to RunJava.java was un-Java-like; It also broke the "java"
CLI command which didn't put "java" in argv[0] for the arguments to
RunJava.main(), so the "java" command no longer worked after the previous
patch.

Instead, we change java.cc (which compiles to java.so). This is what
calls RunJava.class, and it should remove the new argv[0] before calling its
main() - instead of expecting that RunJava.class to do this.

the convention in linux is that argv[0] holds the program executable.
I had an attempt to run netserver not from the CLI and it didn't work because
its argument parsing got broken.

Added the possibility to pass to cli.jar a command, which it runs instead
of taking commands interactively. Note that the initialization script is
run before the given command.

After this patch,

        scripts/run.py -e "java.so -jar /java/cli.jar"

Continues to run the interactive command line editor loop, as before.
But additionally, one can do:

        scripts/run.py -e "java.so -jar /java/cli.jar ls"

To run just the command "ls" and exit - exactly as if the user would type
this command on the command line and exit the VM.

The given command can be, of course, much longer. For example to run Jetty
after the CLI's normal initialization script, the following monster can
be used:

scripts/run.py -n -e "java.so -jar /java/cli.jar java -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration /jetty/jetty.xml"

(Funny how a single command should say "java" 3 times and "jetty" 4 times :-))

java.cc would exit right after the main() method finished. But in Java,
this is not the correct behavior. Rather, even if main() returns, we
need to wait for all other threads to end (or more accurately, wait
for all threads not marked with setDaemon(true)).

Calling jvm->DestroyJavaVM() does this for us, and it's probably the
Right Thing(TM) to do anyway.

Before this patch, the Jetty benchmark exited immediately after
startup.  After this patch, its worker threads keep the whole VM running.

Java.so used to correctly support the "-jar" option, but did not fully
allow the other "mode" of running Java: specifying a class name which is
supposed to be searched in the class path. The biggest problem was that
it only know to find class files, but not a class inside a jar in the class
path - even if the classpath was correctly set.

Unfortunately, fixing this C code was impossible, as JNI's FindClass()
simply doesn't know to look in Jars.

So this patch overhauls java.so: Java.so now only runs a fixed class,
/java/RunJava.class. This class, in turn, is the one that parses the
command line arguments, sets the class path, finds the jar or class to
run, etc.. The code is now much easier to understand, and actually works
as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*"
benchmarks, which forced us to tweak the class path manually.

The new code supports running a class from the classpath, and also the
"-classpath" option to set the class path. Like the "java" command line
tool in Linux, this one also recognizes wildcard classpaths. For example,
to run Jetty, whose code is in a dozen jars in /jetty, one can do:

        run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"

the new test creates several thread, each is downloading a ~280MB file
concurrently. It aims to find concurrency bugs in the netport, dead locks,
etc... but (fortunately) it pass.

making it even more stressful ;)

now it downloads a ~200MB file and validating md5 on it.

As Nadav found out, we don't have to call defineClass and register each visible
Java class within the js scope, this makes it much simpler to integrate with Java
from the cli.

Not provided by the musl headers, and also unneeded.

Until now, OSV's console defaulted to raw mode, to make the CLI
happy. The problem is that on Linux, applications expect to be
run in cooked mode, so if we ever run a simple application that
tries to read user input, it can be confused.

This patch makes OSV console default to cooked mode, and the
CLI switch to raw mode before reading an input line - and reset
to the default mode just before running the user's command.

Unfortunately, we had to resort to adding a JNI class "Stty",
since Java has no builtin support for the ioctls required for
changing the tty settings.

uses Java nio.* for downloading a file, writing it to /tmp

requires starting qemu with tap networking, first install libvirt
then launch the run script as root with the -n option.

Example:

$ sudo ./scripts/run.py -d -n

in osv you'll have to configure networking as follows:

$ ifconfig virtio-net0 192.168.122.100 netmask 255.255.255.0 up
$ route add default gw 192.168.122.1

SPECjvm2008, uses the Thread.getContextClassLoader() class loader
to load classes - instead of using the current class-loader as any
decent code does when using reflection.

To allow this ugly, but officially supported, usage, we need to
set the context class loader in RunJar.java.