add configuration options to control Cassandra compression
Making Cassandra compression algorithm configurable via two new configuration properties (storage.sstable-compressor and storage.compression-chunk-length)
Merge branch 'issue_379'

Conflicts:
	titan-cassandra/src/main/java/com/thinkaurelius/titan/diskstorage/cassandra/astyanax/AstyanaxStoreManager.java
	titan-cassandra/src/main/java/com/thinkaurelius/titan/diskstorage/cassandra/thrift/CassandraThriftStoreManager.java
Merge branch 'master' of https://github.com/mamccr/titan into mamccr-master

Conflicts:
	titan-cassandra/src/main/java/com/thinkaurelius/titan/diskstorage/cassandra/AbstractCassandraStoreManager.java
	titan-cassandra/src/main/java/com/thinkaurelius/titan/diskstorage/cassandra/astyanax/AstyanaxStoreManager.java
	titan-cassandra/src/main/java/com/thinkaurelius/titan/diskstorage/cassandra/thrift/CassandraThriftStoreManager.java
Refactor Cassandra's sstable_compression config

* Renamed SSTABLE_COMPRESSION in AbstractCassandraStoreManager to
  COMPRESSION_KEY to match the existing pattern of public static final
  String config keys in that class

* Added psfS DEFAULT_COMPRESSION set to "SnappyCompressor" instead of
  passing the literal directly to the config parsing code

* Changed user-visible "sstable-compression" configuration key to
  "cassandra.db.compression.sstable_compression" to match the pattern
  of the other two Cassandra-compression-related config keys.  I think
  having "Cassandra" is definitely redundant, and "db" is probably
  redundant, so I may change this again.
Refactoring CF compression in embedded Cassandra

* Added support for disabling compression entirely in the embedded
  cassandra adapter per the config key introduced in #379

* Removed code that instantiates a compressor class from the embedded
  store manager, instead passing a string to Cassandra's
  CompressionParameters constructor.  The constructor handles
  reflective instantiation on our behalf.  This is an improvement
  because CompressionParameters contains logic to prepend
  "org.apache.cassandra.io.compress." to compressor strings that
  contain no dots, allowing shorthands like "SnappyCompressor".
  That's also our current default compressor string.

* Expanded debug log statements around compressor configuration in the
  embedded adapter
Renaming Cassandra compression config keys

Removed the "cassandra.db." prefix from these Cassandra configuration
keys:

* compression.enabled
* compression.chunk_length_kb
* compression.sstable_compression

Also: the middle option in the list was formerly chunk_size_kb.  I
changed it to chunk_length_kb because that's the string Cassandra uses
and I don't see a reason why the need to be subtly different.

I think the "cassandra" prefix is redundant because graph configs have
"storage.backend", which must be set to a one of the strings
identifying a Cassandra backend for any of these keys to be read by
Titan in the first place.  "db" is debatable.
Minor javadoc on KeyRangeQuery
Monster getKeys refactoring and testing commit

The getKeys(KeyRangeQuery keyQuery, StoreTransaction txh) method in
the Astyanax and Thrift stores seemed to be untested and broken.  This
is the getKeys method that takes both a column range and key range.
Its only supported when the backend stores keys in byte order (BOP, in
this case).

The Thrift adapter had these bugs:

* For Cassandra versions 1.2.4 and earlier,
  https://issues.apache.org/jira/browse/CASSANDRA-5566 makes the
  client send broken slice tokens when BOP is in effect.  The server
  can't parse the tokens, logging an error and triggering an exception
  client-side.  Slicing by key is not affected -- only by tokens.
  This has a pretty simple workaround, and it goes away in 1.2.5 and
  up.  I actually already verified that it's fixed on 1.2.10, but then
  I had to revert to 1.2.2 when I discovered that Astyanax has a hard
  incompatibility (trying to call a nonexistent constructor) with
  1.2.10.

* The ordered getKeys checked for `partitioner instanceof
  OrderPreservingPartitioner` and threw an exception if false.  But
  this is always false with BOP.  BOP doesn't inherit from OPP and
  never has AFAIK (= moderate certainty back to about 0.7).  Changed
  OPP in the instanceof check to AbstractByteOrderedPartitioner.  I
  have an extremely strong sense of déjà vu about this bug, but I
  don't know where in the revision history I might have previously
  fixed it, if at all.

* The last key was returned by the ordered getKeys method.  Judging
  from KeyRangeQuery and the tests for this method, I think the last
  key is supposed to be considered exclusive.

The Astyanax adapter just had the last bug in the list above.  I fixed
all of the above (I think).

I fixed the first bullet point about junk BOP tokens in a
forward-compatible way.  When we go to 1.2.5 and beyond, the
workaround should quietly turn itself off at runtime.  Then we can
remove it as soon as we're ready to drop compatibility with prior
versions.  I also added forward-compatibility to
CassandraThriftStorageManager's token handling; it wasn't buggy on our
current Cassandra version, but it would have failed when we eventually
upgrade to 1.2.5 and beyond.

I refactored Cassandra tests and the way Maven runs them.  By default,
all Cassandra tests now run twice with Maven: once under BOP and once
under RP.

Test classes or methods can be marked as eligible for only BOP or RP
by annotating them with

 @Category({ UnorderedKeyStoreTests.class })

or

 @Category({ OrderedKeyStoreTests.class })

There is also an annotation which explicitly declares the subject
compatible with either type of store, but it is redundant, because
that is the default behavior under the current Maven config:

 @Category({ KeyOrderAgnosticTests.class })

All of the annotation argument classes are in the package
com.thinkaurelius.titan.testcategory in titan-test.

Eclipse's native JUnit runner appears to have no way to honor the new
JUnit @Category annotation, so it will blithely try to run all tests
regardless of their categories using the default config, which I've
set to BOP.  When Eclipse runs an BOP-only test with a RP config, it
fails.  I haven't found a clean way to workaround that yet.  We could
make all the tests interrogate StoreFeatures to see what's possible,
but that will add some boilerplate.  It would be worth the boilerplate
to get the tests to "just work" in Eclipse though.

Finally, both ExpectedValueCheckingStore and
BufferedKeyColumnValueStore had bugs in both of their getKeys methods:
the one that takes a SliceQuery and the other that takes a
KeyRangeQuery.  They weren't unwrapping their transactions when
interacting with the wrapped store.

I also finished removing Rexster classes, test classes, and Maven
dependencies.
Better GraphQuery execution to take advantage of multiple indexes covering a single index. This takes care of the performance aspect of #373.
Added and fixed additional test cases for index handling.
Reverting maven-surefire from 2.16 to 2.15

2.16 included a regression that makes it impossible to run a single
test method.  It's still possible to run all methods in a single class,
just not a specific method.

 http://jira.codehaus.org/browse/SUREFIRE-1028

According to the 2.16 changelog in JIRA, the only substantial changes
vs 2.15 were new parallel test execution options, none of which we
actually use right now.  I do use single-method test execution though.

 http://jira.codehaus.org/browse/SUREFIRE/fixforversion/19331
Make BytesToken format hack safe on other tokens

Check that objects of general type Token<?> pass an instanceof
BytesToken check before trying to apply a hack for
https://issues.apache.org/jira/browse/CASSANDRA-5566

I think it was impossible for the hack to have fired prior to this
commit.  It was guarded by a regex on Token strings that looked for
"Token(bytes[.+])".  Murmur3- and RandomPartitioner return LongToken
and BigIntegerToken, respectively, whose toString() methods both
return strings containing only decimal digits and a minus sign.

Still, I think the check is useful in case somebody has a third-party
partitioner that uses tokens returning arbitrary strings.
Add Cass storemgr method to get IPartitioner
Rewrite getKeys methods in CassandraThrift

Also added new getKeys test methods to AbstractCassandraKCVSTest and
KCVSTest
Commit cleanup in AbstractCassandraKCVSTest
Import, warning, and loglevel cleanups
Obsolete commented code deletion
Import and warning cleanup in CassandraThriftStore
Testing, import, and unused variable cleanups