This allows users to escalate a graceful shutdown to a forceful one if
there are active connections that are taking too long to finish their
requests.

Fixes #94.

This allows users to signal Goji to exit ungracefully by means of
sending two signals in quick succession.

This backends to the listener.DrainAll functionality I just added,
allowing impatient users to shut down their services immediately and
un-gracefully if they want.

This is now controlled at the top level goji package: these packages are
not even compiled in when using App Engine. This is sensible, since
neither package is of any use there.

Exactly the same code, just (hopefully) organized a little more
sensibly.

This change makes package graceful/listener track all connections that
have been Accepted, not just the ones considered idle. The motivation
here is to support a DrainAll function on graceful listeners, allowing
users an alternative to patiently waiting (potentially forever) for
in-use connections to become idle.

It was exposed mostly for documentation of a Go 1.2 polyfill, and really
doesn't feel like it should be exposed long-term, since it hasn't done
anything in frightfully long.

This is a breaking change for advanced users of package graceful, for
which there is unfortunately no easy workaround (at least for Go 1.2
users, which are the ~only ones affected).

This change addresses the POODLE vulnerability [0]. Unfortunately it
makes package graceful's behavior here slightly different than the stock
net/http methods of the same name, but I think that's fine in this
situation.

[0]: https://www.openssl.org/~bodo/ssl-poodle.pdf

Thanks to @ekanna for reporting this. Fixes #101.

This change refactors package graceful into two packages: one very well
tested package that deals with graceful shutdown of arbitrary
net.Listeners in the abstract, and one less-well-tested package that
works with the nitty-gritty details of net/http and signal handling.

This is a breaking API change for advanced users of package graceful:
the WrapConn function no longer exists. This shouldn't affect most users
or use cases.

This is meant to accomplish a few things:
1. graceful no longer spawns an additional goroutine per connection.
   Instead, it maintains a sharded set of idle connections that a single
   reaper goroutine can go through when necessary.
2. graceful's connection struct has a more orthogonal set of connection
   state flags, replacing the harder-to-understand state machine. The
   underlying mechanics are largely the same, however.
3. graceful now uses the Go 1.3 ConnState API to avoid the "200-year
   SetReadDeadline hack." It still falls back on SetReadDeadline on Go
   1.2 or where ConnState does not apply.

This feature can be used in place of the pile of hacks in middleware.go,
and doesn't involve awkwardly shimming out a http.ResponseWriter. Sounds
like a win-win!

The result of this was that builds were broken on windows and app
engine.

Fixes #59.

Fixes #52.

Previously, a set of standard signals would be handled automatically via
an init() function, however that made the package difficult to use in
packages in which an HTTP server would only be spawned some of the times
(perhaps keyed on an environment variable or flag). Now, signals must be
registered manually.

By default, the top-level "goji" package automatically registers
signals with graceful, so this will result in no behavior changes for
most people.

Fixes #35.

graceful.Server was made private in 05c2ca7e, but I think the increased
flexibility you get with being able to provide your own TLS options
(etc.) outweighs the API complexity of an additional type.

For sendfile(2) support. I should really DRY up the implementations here...

Apparently stdlib support will be in Go 1.3. Yay!

Package graceful provides graceful shutdown support for net/http servers,
net.Listeners and net.Conns. It does this through terrible, terrible hacks, but
"oh well!"