Misconfigured DNS should not ban *successful* ssh logins

Noticed while looking at the source (to see the point of ssh-ddos).

POSSIBLE BREAK-IN ATTEMPT - sounds scary?  But keep reading
the message.  It's not a login failure.  It's a warning about
reverse-DNS.  The login can still succeed, and if it _does_ fail,
that will be logged as normal.

<exhibit n="1">
Jul  9 05:43:00 brick sshd[18971]: Address 200.41.233.234 maps to host234.advance.com.
ar, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Jul  9 05:43:00 brick sshd[18971]: Invalid user html from 200.41.233.234
</exhibit>

The problem (in my mind) is that some users are stuck with bad dns.
The warning won't stop them from logging in.  I'm pretty sure they can't
even see it.  But when they exceed a threshold number of logins -
which could be all successful logins - fail2ban will trigger.

fail2ban shouldn't adding additional checks to successful logins
 - it goes against the name fail2ban :)
 - the first X "POSSIBLE BREAK-IN ATTEMPT"s would be permitted anyway
 - if you want to ban bad DNS, the right way is PARANOID in /etc/hosts.deny

I've checked the source of OpenSSH, and this will only affect the
reverse-DNS error.  (I won't be offended if you want to check
for yourself though ;)

<exhibit n="2">
$ grep -r -h -C1 'ATTEMPT' openssh-5.5p1/
                logit("reverse mapping checking getaddrinfo for %.700s "
                    "[%s] failed - POSSIBLE BREAK-IN ATTEMPT!", name, ntop);
                return xstrdup(ntop);
--
                logit("Address %.100s maps to %.600s, but this does not "
                    "map back to the address - POSSIBLE BREAK-IN ATTEMPT!",
                    ntop, name);
$
</exhibit>
BF: (python 2.4) -- access to staticmethod should go via Class

TODO: get away from using all those staticmethods in f2b
BF: in code we should use MyTime wrapper instead of time module directly

to allow for some tests to work correctly
Added in command option to unban and IP, just like using 'banip'.  Command looks like: fail2ban-client set <jail name> unbanip <ip>
ENH: refactored previous commit to make it more Pythonic (With prev commit closes gh-86, gh-81)
Added in while loop to process the Fail Manager after the requested banned IP was added to its queue.  This solves the issue of needing to touch the log file that is being monitored to get the IP to be banned accordingly.  Added in import of FailManagerEmpty exception class.
DOC: minor "fixes" in DEVELOP
Merge pull request #64 from sourcejedi/remove_sshd_rdns

Misconfigured DNS should not ban *successful* ssh logins

Per our discussion indeed better (and still as "safe") to not punish users behind bad DNS
minor: added a note on now "negative" log entries on "POSSIBLE BREAK-IN ATTEMPT"
ENH: downgrade "already banned" from WARN to INFO level (Closes gh-79)

Most of the time it is a benign latency effect so nothing to warn about.
DOC: forgotten --help entry for " unban "
BF: do not enable pyinotify backend if pyinotify is too old (Closes gh-80)
NF: rudimentary .travis.yml for travis-ci.org service
ENH: travis -- try to run tests against all available python versions
BF: added a little shell script to excercise tests against all available Python versions

also report Python version inside fail2ban-testcases
BF: typo
ENH: trying to go native travis-ci python way to take advantage of virtualenv's with older pythons
ENH: To help with gh-87 added hints into the log on some failure return codes (e.g. 0x7f00 for this one)
ENH: fail2ban-testcases-all -- pass cmdline options to fail2ban-testcases
ENH: until we make it proper module -- adjust sys.path only if system-wide run