[retrieval] address some CR, work around counting bug

Addressed CR: http://barkeep.sv2/commits/hastur-server/6a41a2103b45971330301b28c3eb147985cbd40f

add_counts_to is buggy in a few situations, so just rescue nil for now and deliver
data without counts. I'll take another look at it after discussing with the team to
decide what to do. I'm leaning towards dropping the counts since they're not very
useful in most use cases, and are almost never accurate outside of single node/message
queries.
[retrieval] use &:uniq! per CR

Good catch Noah. Feels a tiny bit faster according to my fleshy dynometer.

http://barkeep.sv2/commits/hastur-server/6a41a2103b45971330301b28c3eb147985cbd40f
[test] adjust test to not use raw=true and drop count fields

Further commits will remove counts / uuid_count / etc. from the retrieval service.

They were broken and misleading and polluted the top-level of the hash, making iteration
over uuid's really clunky.
Bump hastur req to 1.2.8 for bugfix to Hastur.time
[test] update schema test to support now-defaulted consistency parameter
[cassandra/schema] light refactoring

Merge two nearly identical blocks into the row_keys method call that generates
a list of row keys from a list of uuids, a bucket size, and timestamp. This method
is documented.

Use a local constant for consistency that's easier to keep in sync with tests that
will break if it changes.

Add a note in lookup_by_key to call out the fact that its time bucket is not currently
configurable.
[retrieval] refactor query_hastur & others

No features have been added. Count fields have been removed.

Converted all param access to use symbols. Sinatra takes either and we were
using both so I made it consistent.

query_hastur was way too big and, therefore, hard to follow, so I broke it into
digestible pieces, each with its own YARD.

I'd like to have cleared out most of the direct parameter access so it could move into
cassandra/query.rb or something along those lines, but it's still really closely tied
to HTTP query params.

Since the count fields were pretty much guaranteed to be inaccurate with
multiple uuids or names, they've been removed.  This cleans up the root of the structure
so most simple cases can iterate over keys and get only UUID's. The types sub-hash is gone
too since it was being computed in the add_counts_to() method. We'll see if it's missed.
Removed keys: uuid_count, name_count, count, types

Cleaned up some error reporting.

Only get Hastur.timestamp once, at the beginning of each request so multiple calls to
get_start_end can always use the same timestamp.

The two data translation blocks for resorting series keys and deserializing json have been
converted to pure-ish functions - the no longer try to modify the hash in-place and are
measurably faster in my unscientific tests. In any case, they're safer & easier to read.

Renamed uuids_for_name, changed its format, and updated all of its callers. It now returns
all the data it gets back from Cassandra. The type information turned out to be handy to save
6-7 round-trips to the DB for name/type combos that don't exist in /api/name/:name queries. This
same optimization can probably be applied to other routes if the cost of the lookup pays off
in reality (it saves time on my test setup but round trips are extra expensive there).

Removed the extra json() option for pretty printing again and just use params[:pretty].

Breaking up this commit would require a bogus patch series of adding the new methods then converting,
but I didn't feel it's worth the effort since no major functionality changed.