Rename PipeViwerRateLimitFilter to PipeViewerRateLimitFilter

This was a typo.
Run tests on Travis CI
Add Timothée Peignier as a contributor
While transferring WAL ensure concurrent greenlets can clean up

There have been some reports that WAL-E can leave around temporary
files pathologically often.

This is because when an error is propagated to the main greenlet,
there's a good chance that it will exit the process before allowing
the other concurrent greenlets to clean up: instead, those greenlets
are abruptly terminated, and in doing with temporary files are leaked.

This bug probably exists elsewhere in WAL-E (e.g. base backups), but
the introduction of parallel WAL upload has rendered its effect
uniquely noticeable to date, probably because so many of
start-up-shut-down cycles of WAL-E are performed in a short period of
time, and each such cycle is an opportunity to leak these files given
an error condition.
Update cipher string and explain it with more detail

I don't think this makes a functional difference, but the intent
behind each component is now more clear.  These decisions were
informed by reading OpenSSL's s2_lib.c and s3_lib.c.

The express banning of DES has been lifted, because per the standard
DES is too weak a cipher to be in 'HIGH'.  The forbidding of 3DES,
which can have long enough keys to be in the 'HIGH' category, is still
explicitly forbidden for performance reasons.

SSLv2 has been expressly banned for lucidity sake, even though it is
not strictly necessary given "!3DES": thanks to accidents of history
the only 'HIGH'-class cipher suite present is based on 3DES.  Thus
'HIGH:[...]:!3DES' should be sufficient to the same meaning, but only
through a close reading of the availability of what's in SSLv2.

Also deny use of cipher suites using MD5.  It's not clear this can
mount a practical attack against a SSLv3 session, and seems even less
likely so in TLS v1.0+ since they use HMAC, where MD5 is thought to be
fine, but given that flavors of SHA are widely deployed and thought to
be stronger, it doesn't seem such a ban will be of predicable
practical consequence to compatibility.

At the time of writing, the cipher suites that OpenSSL will support
given these constraints are:

$ openssl version
OpenSSL 1.0.1c 10 May 2012

(Line breaks inserted for clarity below)

$ openssl ciphers 'HIGH:!aNULL:!SSLv2:!RC4:!3DES:!MD5'
ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-AES256-GCM-SHA384:
ECDHE-RSA-AES256-SHA384:
ECDHE-ECDSA-AES256-SHA384:
ECDHE-RSA-AES256-SHA:
ECDHE-ECDSA-AES256-SHA:
SRP-DSS-AES-256-CBC-SHA:
SRP-RSA-AES-256-CBC-SHA:
DHE-DSS-AES256-GCM-SHA384:
DHE-RSA-AES256-GCM-SHA384:
DHE-RSA-AES256-SHA256:
DHE-DSS-AES256-SHA256:
DHE-RSA-AES256-SHA:
DHE-DSS-AES256-SHA:
DHE-RSA-CAMELLIA256-SHA:
DHE-DSS-CAMELLIA256-SHA:
ECDH-RSA-AES256-GCM-SHA384:
ECDH-ECDSA-AES256-GCM-SHA384:
ECDH-RSA-AES256-SHA384:
ECDH-ECDSA-AES256-SHA384:
ECDH-RSA-AES256-SHA:
ECDH-ECDSA-AES256-SHA:
AES256-GCM-SHA384:
AES256-SHA256:
AES256-SHA:
CAMELLIA256-SHA:
PSK-AES256-CBC-SHA:
ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES128-GCM-SHA256:
ECDHE-RSA-AES128-SHA256:
ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA:
ECDHE-ECDSA-AES128-SHA:
SRP-DSS-AES-128-CBC-SHA:
SRP-RSA-AES-128-CBC-SHA:
DHE-DSS-AES128-GCM-SHA256:
DHE-RSA-AES128-GCM-SHA256:
DHE-RSA-AES128-SHA256:
DHE-DSS-AES128-SHA256:
DHE-RSA-AES128-SHA:
DHE-DSS-AES128-SHA:
DHE-RSA-CAMELLIA128-SHA:
DHE-DSS-CAMELLIA128-SHA:
ECDH-RSA-AES128-GCM-SHA256:
ECDH-ECDSA-AES128-GCM-SHA256:
ECDH-RSA-AES128-SHA256:
ECDH-ECDSA-AES128-SHA256:
ECDH-RSA-AES128-SHA:
ECDH-ECDSA-AES128-SHA:
AES128-GCM-SHA256:
AES128-SHA256:
AES128-SHA:
CAMELLIA128-SHA:
PSK-AES128-CBC-SHA
Shorten cipher string documentation

This information is maybe not quite correct (the cause of selection of
a cipher suite by S3 is a little mysterious) and flat out wrong when
it comes to the use of DES: 3DES is used, even if it is sometimes
rendered as DES with a long key.