It seems ssh is kind of stupid and uses a really big SO_SNDBUF (hundreds of
kbytes).  Thus, we can't depend on the socket's output buffer to limit our
latency down to something reasonable.  Instead, limit the amount of data we
can send in a single round trip.

Otherwise a single busy stream can ruin it for everybody.

This way we don't freeze the entire proxy when someone tries to connect to a
nonexistent IP address (oops).

We'll introduce a new "Fatal" exception for this purpose, and throw it when
we just want to print a user message and abort immediately.

If you run sshuttle on a router, it can handle vpn'ing for all the boxes on
your network.

Some fds don't have peernames, and sometimes the peername isn't very
helpful, so let's fill it in by hand when appropriate.

Turns out list.pop() removes the *last* item, not the first one.  Oops.  It
all works great for queues of only one item... :)

There still seem to be some weird timing and/or closing-related bugs, since
I can't load the eqldata project correctly unless I use --noserver.

We'll need this when we have a SockWrapper pointing at a Mux on a subprocess
pipe.

Currently the 'server' is just a pipe to run 'hd' (hexdump) for looking at
the client-side results.  Lame, but true.

Now if we aren't given an explicit port, we always initiate the port search
at 12300 and count upward looking for an available port.

Normally the kernel will assign us a random port, but that's not ideal
in our case because we'd like to use the same port numbers whenever
possible; that avoids piling up crap inside iptables in the (hopefully
unlikely) event that we die without cleaning up correctly.

Doing it in python instead of shell makes the code a bit less error prone.
Plus we can parse the iptables output and avoid triggering iptables errors.

When regenerating outgoing connections, we set TTL=42 to prevent re-proxying
of requests.  That's a little hacky, but at least it avoids infinite loops.

Importing options.py, ssh.py, and LICENSE from the bup project.