Feature branch, modify Sanford configuration and startup logic

This is an effort to modify Sanford to work more like Deas in how
it is configured and is started. The goal is to make them similar
and also simplify some of the oddities of working with Sanford.
This will change the CLI to take a configuration file, which is
expected to define a Sanford server. The server will contain all
the configuration for the IP, port and other options. The server
will have (or be given) a router. The router will be where
services are routed. Service handlers will continue to work as
they previously did. This branch is a collection of the changes to
get the changes working as expected.
Add `Router` and `Route` for routing and running services

This adds a `Router` and `Route` class. The `Router` will replace
part of the `Host` and `HostData` logic for routing services. This
also adds a `Route` class that will be built when a service is
added to the router. This will handler building and running a
`SanfordRunner` and returning the response. This follows Deas'
implementation and is part of the effort to modify Sanford's
configuration and startup logic.
Merge pull request #109 from redding/jcr-add-router

Add `Router` and `Route` for routing and running services
Update to use the new DatTCP, rename server to server old

This updates Sanford to work with the latest DatTCP but also
renames server to server old. This is done to make room for
reworking the server without breaking sanfords full functionality.
Until we are ready to switch to the new server logic, the old
logic can continue to be function. This switches to using the
new DatTCP with leaving the server logic as unchanged as possible.
This doesn't change any functionality, just switches out to the
new DatTCP and renames the server.
Merge pull request #112 from redding/jcr-new-dat-tcp

Update to use the new DatTCP, rename server to server old
Add new `Server` DSL

This adds a new `Server` and the DSL for configuring it. This is
part of the effort to rework the `Server` and startup process for
Sanford. This moves most of the `Host` configuration over to the
`Server` and the DSL for configuring it as well. This also moves
the template source configuration to the `Server` from the
global Sanford config. Both the `Host` and `Config` will be
removed later in favor of the new `Server`.
Merge pull request #113 from redding/jcr-change-server

Add new `Server` DSL
Add `Server::ConfigData`, make `HostData` compatible

This adds `ConfigData` to the `Server`, which replaces part of the
role that `HostData` currently handles. `HostData` is the
"compiled" data from a `Host`. Similarly, `ConfigData` is the
"compiled" data from the server's `Configuration`. This is done
for speed because `NsOptions` is relatively (when 1-5ms matters)
slow in reading options.

The `ConfigData` is built when the `Server` is initialized and is
seeded by the `Configuration` data. It also handles looking up
routes given a name. The `Server` will use this to find the service
handler it needs to run for a request.

`ConfigData` will also be used by the `ErrorHandler` when an
error occurs. To handle `Sanford` currently using the `HostData`
but needing the `ErrorHandler` to also work with `ConfigData`, I
made their interfaces mostly compatible. This allows updating
the `ErrorHandler` to use `ConfigData` but not breaking the build
which uses the `HostData`. In this case, I didn't want to create
two error handlers, one that worked with `ConfigData` and one
that worked with `HostData`.

All of this is setup for switching out the old server for the new
one.
Merge pull request #114 from redding/jcr-server-config-data

Add `Server::ConfigData`, make `HostData` compatible
Create `WorkerOld`, copy of `Worker`

This is setup for changing `Worker` to work with the new `Server`.
This takes the current worker logic and moves it to `WorkerOld`
and updates everything using `Worker` to use `WorkerOld` instead.

I did this to free-up the `Worker` name but I also wanted to
preserve the diff from the old worker logic to the new worker
logic which will come in a separate commit. That's why I left the
old worker logic in `sanford/worker.rb`.
Merge pull request #115 from redding/jcr-move-worker

Create `WorkerOld`, copy of `Worker`
Update `Worker` to work with `Server::ConfigData`

This updates the `Worker` to work with the `Server::ConfigData`.
Overall, the worker works as it previously did. It takes a
connection and config data, and when run, reads the request,
runs a service handler and writes a response. The biggest
difference is that it now looks up a route via the config data and
then runs the route, passing it the request and the config data
logger. Previously, it would get the handler class from the host
data and then have the host data run the handler class, passing
the request. This is part of switching to the new server logic.
The new `Server` will run this `Worker` similar to how the old
server logic runs the old worker now.

This also adds proper unit tests for the worker tests which
basically weren't done for the old worker logic.

Finally, this removes `version` from the summary logging. This
should have been done when we removed version as a part of a
request, but was missed.
Merge pull request #116 from redding/jcr-new-worker

Update `Worker` to work with `Server::ConfigData`
Build DatTCP server when initializing a Sanford server

This updates the new server logic to build a DatTCP server. This
allows the Sanford server to actually listen and serve connections
made to it. This adds the same socket handling behavior as the
old server logic, only it builds and runs a new worker. This also
adds all the same configuration and socket handling from the old
server logic. The TCP server will have the `TCP_NODELAY` option
set on it and in a linux environment, the client socket will
be "corked" as before. This finishes the main work on the
new `Server` logic and it can now replace the old server logic
in the test suite.

This also fixes a few mistakes made in previous commits. The
configuration now adds its routes and error procs to its hash.
Otherwise the config data won't ever get them. I also updated the
`router` DSL method to take a block so services could be added
to the router via the server definition.
Merge pull request #117 from redding/jcr-server-build-dat-tcp

Build DatTCP server when initializing a Sanford server
Switch to testing the new `Server`, remove the old `Server`

This switches the test suite over to testing the new `Server`
and removes `ServerOld`, `WorkerOld` and all the testing
that went with them. This reworks the request handling system
tests as server system tests and runs them against the new server
logic. This ensures that the new server should handle requests
like the old one did.

This puts in a hack to get the new server logic working with the
existing CLI/manager logic. It builds an anonymous service class,
using the host configuration for the servers configuration. This
works, but is not going to be the way this is handled going
forward. This is temporary so the bench scripts can be run and
so we don't have Sanford in a broken state.

Finally, I found a "bug" that I believe was introduced with the
latest DatTCP (v0.5). I found that after hot restarting, I would
get a random `SignalException: SIGALRM` that would cause the
process to exit. I found this is a "bug" with the manager
implementation of restarting. The problem is the manager runs all
the restart logic in the trap for the restart signal, which is a
bad practice. Because DatTCP pauses so quickly, the original
thread for the server doesn't get to exit appropriately before
we run `exec` and replace the process. This seemed to cause the
`SIGALRM`. I found that if I just turned on DatTCP logging, which
should slightly slow it down when being paused, the issue would
go away. To handle this, I patched the restart logic to join the
server thread and make sure it exits before calling `exec`. This
cleared up the problem and confirmed my suspicions that the
thread was not properly exiting.
Merge pull request #118 from redding/jcr-server-system-tests

Switch to testing the new `Server`, remove the old `Server`
Add `PIDFile` for managing a Sanford process PID file

This adds a helper class for managing a Sanford process PID file.
When a Sanford process is started, it writes its PID file to a
configured path. This is used to control the Sanford process when
using the CLI. When a stop, halt or restart command is given, the
PID file will be read and a TERM, INT or USR2 signal will be sent
to the process. This logic will be used by both the building and
running a Sanford process set of logic and the sending signals
to a Sanford process set of logic.
Merge pull request #119 from redding/jcr-pid-file

Add `PIDFile` for managing a Sanford process PID file
Add `Process` logic, for running a Sanford server process

This adds the logic related to running a Sanford server process.
This logic replaces the `Manager` logic and will be used by the
CLI. The `Process` class takes a server and sets up the current
ruby process for it when run. This involves optionally daemonizing
the process, managing a PID file, and starting the server. The
process also traps signals for controlling the process after its
running. The server returns a thread when its started and this is
joined to the main thread, so the process will continue forever
until it receives a signal. It is setup to receive `TERM` which
will stop it gracefully, `INT` which will halt it immediately (not
graceful), and `USR2` which will perform a hot restart. To perform
the hot restart, the process runs a `Kernel.exec` which replaces
the current process with the new process defined by the args passed
to the `exec`. The TCP server is only paused when this happens, so
its still accepting connections, just not processing them.

This also requires that the server have a name since the `Process`
logic uses it to name the system process and also in logging. This
is handled in the configuration validation, which is called when
the server is initialized.

This fixes some bad practices in the old `Manager` logic related
to the trapping of signals. The server commands for `stop`, `halt`
and `pause` do not perform any of the logic for actually stopping
the server. They proxy DatTCP which simply writes the command to
a `IO.pipe` and then exits. The original thread running the server
then gets this and handles shutting down the server as needed.
This is a better practice than doing all the processing in the
actual signal traps. I ran into problems with the old logic that
are not present with this implementation.