closes #20 added metrics instrumentation and configuration to Fluo
Closes #313 - Hibernate validator jar missing from Twill classpath
Merge pull request #309 from keith-turner/fluo-20

closes #20 added metrics instrumentation and configuration to Fluo
closes #312 added hash to beginning of trie node
Merge pull request #315 from keith-turner/fluo-312

closes #312 added hash to beginning of trie node
fixes #19 #282  Major improvement in how notifications to process are found

This commit does a few things.

 * Reorganizes code to separate finding work and executing work
 * Now uses a single thread per worker to find work (could easily run multiple finder threads)
 * Introduces new method of partitioning work by hash+mod of notifications

Using hashes should completely avoid the case of multiple workers processing
the same notifcation, in the case of a stable set of workers.  As worker
processes come and go, there is the possibility of small amount of duplicate
processing, however this should be for a short time period.  Each worker reacts
aggressively to the total number of workers changing. Using hash mod also
evenly distributes work.

A possible draw back of the hash technique is that each worker process has to
scan the entire table locality group to find all of its work.  This may not
scale well for really large clusters, however I think this new approach will
scale much much better than the code it replaced.  I feel like is a really good
and simple solution for up to medium sized clusters.  Uncertain about large
clusters.  This patch does use an Accumulo iterator to the the actual hash mod,
so that avoids all workers bringing all notifications to the client side.  I
suspect that if Accumulo compacted locality groups separately, that the delete
markers in the notification localitly groupd could be cleaned up making
hash+mod scale well.

Now that its possible to implement multiple work finders. Could implement the
method mentioned in the percolator paper in the future.  The papers mentions
chosing a random table, random row in the tablet, and then using a light weight
lck service to avoid collisions.  The hash+mod approach allowed me to avoid
collisions w/o implementing a LWLS (light weight lock service) :)  I do not
think ZK would be well suited for this LWLS (there is no need to persisted and
would need to support many more locks per second than I think ZK could offer)
Merge pull request #317 from keith-turner/fluo-282

fixes #19 #282  Major improvement in how notifications to process are fo...
Closes #298 - Enable MiniFluo administration from fluo admin script
Merge pull request #318 from mikewalch/fluo-298

Closes #298 - Enable MiniFluo administration from fluo admin script
fixes #323 made FluoConfiguration(Configuration) disable delimeter parsing
Closes #325 - FluoInputFormat is configured for wrong Zookeeper connection property
Merge pull request #324 from keith-turner/fluo-323

fixes #323 made FluoConfiguration(Configuration) disable delimeter parsi...
Merge pull request #326 from mikewalch/fluo-325

Closes #325 - FluoInputFormat is configured for wrong Zookeeper connecti...
Closes #321 - Workers are exceeding default max memory of YARN containers
Merge pull request #327 from mikewalch/fluo-321

Closes #321 - Workers are exceeding default max memory of YARN container...
fixes #329 improved hash notification finders log message
fixes #331 added gauge for notifications queued
Merge pull request #330 from keith-turner/fluo-329

fixes #329 improved hash notification finders log message
Merge pull request #332 from keith-turner/fluo-331

fixes #331 added gauge for notifications queued
Closes #335 - Fluo distribution is including different versions of hadoop jars in lib dir