Refactor storage package's raft interface.

It's still using a dummy implementation, but it no longer relies on
sending channels and mutable reply buffers through raft.
Respond to Tobias and Spencer's code review
Merge pull request #158 from bdarnell/storage-raft

Refactor storage package's raft interface.
Move heartbeat and gossip request/responses to protobuf.

This is anticipation of using other RPC codecs or an entirely different
transport (HTTP/2).

The remaining "icky" bit of this is that infostore deltas are still
encoded using gob. We're going to want to create a protobuf description
of infostore deltas.

I had originally included a protobuf codec but it felt very iffy since
the tests were weak, etc. I feel safer with gob still.
Finish KV client Prepare/Flush; refactor client for simplicity.

This change brings full functionality to client Prepare/Flush
functionality, meaning parallel querying and updates are possible.
This requires unpacking a Batch request on the coordinator and
sending the constituent requests in parallel using goroutines.
I expect further improvements here, in particular, grouping commands
by range and sending those as batches all the way through, but
that'll require some more refactoring and remains down the road.

This change also removes the BeginTransaction command. Instead,
it's now handled seamlessly as part of the first call which goes
through the txn_sender. The advent of the prepare/flush concept
means that a transactional client no longer has to support multiple
goroutines which added a lot of complexity and required the
BeginTransaction command.

There's been a dramatic simplification of the client by doing two
things:

  * Always return a fully updated transaction with the response
    for calls which specify a transaction with the request. This
    allows us to move the priority and timestamp updating to the
    server. The client now only needs to update its transaction
    with the one returned with each response.

  * Move retries due to write intent and write-too-old errors to
    the server. This eliminated the "single-call-sender" and also
    the retry loop in the "txn-sender". Besides simplifying the
    client, this also eliminates a round-trip when resolving an
    intent on a write--I believe this is a significant
    optimization for the common case.

    We are able to move this retry logic into the server (in
    storage/store.go) because I realized that we could simply
    not write response to the response cache for these retryable
    errors. Because there's nothing written, the server is
    completely free to retry (and the client too!) without any
    chance of the client seeing both error and success on
    successive retries.

I also got rid of the increasingly-complex implementation of a
coordinator-like db_test in storage/. Instead, I moved the store
tests which require transactions (to do splits) into a new test
package, storage_test, so we can just use one implementation of
the coordinator (this is what keeps track of intents and cleans
them up).
Response to ben's feedback.
Fixed merge conflicts.
Merge pull request #161 from cockroachdb/spencerkimball/requests-to-protobuf

Move heartbeat and gossip request/responses to protobuf.
Merge pull request #160 from cockroachdb/spencerkimball/batch-command

Finish KV client Prepare/Flush; refactor client for simplicity.
build a static cockroach binary...

...and went a bit down the rabbit hole with regards to building a statically
linked deploy docker image. I'm not much of a C/C++ compiling/linking expert
so I absolutely cannot guarantee that everything done here is sane.

There were a couple of road blocks but I ended up getting there (based on
busybox), and in this version we even compile statically linked test binaries
which are run against (but not included in) the deploy image at build time.
The resulting image runs at about 50MB, 45 of which is our binary.
All the tests pass, and you can put this image into `make acceptance` and it
works like a charm.
However, a few nasty things are left over:

* looking up users from the OS will fail on the static image (not sure we're
  using this right now, but that also triggers a warning on each static build)
* building tests statically doesn't work the same way for all of the packages:
  `gossip`, for instance, will still link to libpthread dynamically no matter
  what. Interestingly enough, using CGO_ENABLED=0 and thus the Go linker, it
  will be ok. Since luckily none of those packages actually needs CGO, I was
  able to hack it into the Makefile by rebuilding all offending tests.
  That's certainly not beautiful.
* I have to build with `-tags netgo` to avoid having the binary try to go
  through glibc (or something like that) and not be able to do networking.
  Not sure if that has any (performance?) implications at all.
* Building `testrace` statically will not work. The test harness Go uses
  to make all the magic happen is probably too complex. I think there were
  errors about libpthread again.

Here's roughly what happens in this change:
* rename Docker image: cockroachdb/cockroach -> cockroachdb/cockroach-dev
* new Docker image cockroachdb/cockroach (deployable statically linked)
* vendored in everything that was left: bz2, zlib, protobuf
* build only static libs for vendored dependency
* you can run `make STATIC=1 {build,testbuild}` and get static files
* moved all build-related things into build/
* renamed "deploy" to "run"
* can supply COCKROACH_IMAGE variable to run/local-cluster.sh
* updated the READMEs (hopefully in all relevant places)
make Docker 1.2 happy
CircleCI: build deploy image
Added support for Protobuf codec and moved RPC system to it.

The support is a modified version of the protorpc package at:
http://godoc.org/code.google.com/p/protorpc.

Our version is modified to support gogoprotobuf. Eventually we'd
like to remove the rpc/codec subpackage and use gogoprotobuf's
implementation. I've started a thread with them for support.
Added tests and updated TODO.md
update godeps with snappy
Added generated .pb.go files
Mergeable Time Series Data

This commit defines a new "TimeSeriesData" message which is used to record time
series data in an efficient way.  It also defines a custom "merge" operation for
TimeSeriesData within our existing RocksDB MergeOperator.

Background:
A "Time Series" is a set of data samples taken from the same statistic at
different points in time - for example, a common use of Time Series is the
recording of metrics for an application. Because of specialized query
requirements and necessarily high write performance, many specialized Database
solutions have been created specifically to handle Time Series data.

In Cockroach, multiple samples of a single statistic will be stored at a single
key; a key will contain all samples taken from a metric during over a well
defined time period such as a wall-clock hour. Based on our research into other
TS database solutions, this grouping is very effective in improving read
performance.

High write performance is enabled by creating a custom Merge operation for Time
Series data.  Whenever metric data samples are written, a Merge operation is
utilized instead of a put; for example, a single metric source will merge
samples into the same key at several points over the course of an hour.  The
resulting "merged" value will appear as if all samples had been written together
as a single value.
fix race in rpc heartbeat test
Merge pull request #164 from cockroachdb/mtracy/add_time_series

Mergeable Time Series Data
Merge pull request #165 from cockroachdb/spencerkimball/proto-codec

Added support for Protobuf codec and moved RPC system to it.