Remove realtime get

The transaction log used by realtime get greatly affects indexing
performance.  Especially since Yokozuna does a delete before every
update in order for sibling support to work correctly.  Since this
functionality is not needed nor used by Yokozuna it doesn't make any
sense to have it enabled.
Return a friendly 404 message when no index is found
No content-type required without a request body
Ignore unused values
Merge pull request #33 from rzezeski/better-http-responses

Searching Nonexistent Index - Better Error Msg
Remove riak_test as dependency

I started this in regards to a potential license issue, which is no
longer relevant, but finished for two reasons:

1. The Riak Test plugin required calling compile twice to actually get
   the tests to compile.

2. Less dependencies means less transitive dependencies which means
   less time to build and less stuff to pull over the network.
JSON-based update commands
Change yokozuna_essential logging back info level

Debug level output is mostly interesting when trying to debug an
issue.  Otherwise it's just a lot of noise.
Pull Solr from Basho S3
Update call to sequential_int_generator
Merge pull request #31 from rzezeski/json-update

Use JSON Update Instead of XML Update
Send AAE status updates

Collect AAE stats for Yokozuna exchanges and hashtree builds.
Remove some AAE log messages to reduce spam
Replace non-existent t_now() with timestamp()
Merge branch 'port-aae-updates'
Use new riak_kv branch

From now on use the yz-merge branch.  All changes to riak_kv can live
on their own branches and periodically the yz-merge branch can be made
by starting from master and merging all feature branches into it.
Update TESTING doc
Factor out common preflist code

This function is also useful to call from the Riak console to
determine where the data for a given {Bucket,Key} lives.
Better log msg for AAE repair
More robust AAE repair

Since AAE tree building is async there are scenarios where an object
is deleted, the Yokozuna hashtree knows it is deleted but KV doesn't,
repair is invoked, but the KV object has already been deleted.  Thus
you can't rely on `get` to return an object.  Futhermore, other error
tuples could be returned but that shouldn't cause the exchange FSM to
crash with `badmatch`.  Instead just ignore it and let the a future
exchange retry the repair if it is still needed.