If the server was having trouble starting, we would print a lot of
unnecessary stuff from iptables.  We shouldn't even have bothered *starting*
iptables if the server was dead anyway.

If we can't communicate with the parent process, he's probably died
unexpectedly; just shut down and don't bother people about it.

Previous versions depended on having 'sudo' in your PATH.  Now that we can
feel safe that --iptables will clean up properly when you exit, and it
doesn't need to authenticate twice, the advantages of sudo aren't strictly
needed.  Good old 'su' is a reasonable fallback - and everybody has it,
which is nice.

Unfortunately su doesn't let you redirect stdin, so I had to play a stupid
fd trick to make it work.

When it happens, it's probably because the client died and the server hasn't
noticed yet.

Now the sudo iptables subprocess persists for the entire life of sshuttle.
The benefits of this are:

- no need to authenticate again at shutdown (failure of which could cause us
  to not clean up iptables)

- if the main process dies unexpectedly, iptables still gets cleaned up

- the password prompt can happen *before* starting the ssh/server process,
  which means it'll stand out and the password prompt won't be overwritten.

Once again, the buffering gets mixed up with the selecting.  Seems to be the
story of my life.

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.