Fix getRawStore method in AbstractStoreClientFactory to bootstrap

with entire stores.xml instead of just storename.
Incorporating code review comments
Releasing Voldemort 1.8.1
Tool for validating avro generic and avro generic versioned

schemas from an input stores.xml
minor reordering and TODO
Improved ValidateSchemaForAvroStores tool

* can recurse sub directories
* can filter for stores.xml
gradle build support for voldemort

1) 'gradle jar' will build binaries that are equivalent to 'ant release'
2) only 'ant release' task is ported to gradle. use 'ant junit' to run
    the unit tests.
3) zip and tar will not be built, unless explicitly requested. by the
   command 'gradle zip' or 'gradle tar' or 'gradle zip tar'

These are the fine level details of the gradle jar
1) The class files has same binary content except for the scala class
files, since it is not used in production, I am ignoring scala as it is
not used in production.

2) The following two lines went missing from the MANIFEST.MF in both
contrib.jar and voldemort.jar
Ant-Version: Apache Ant 1.7.1
Created-By: 20.2-b06 (Sun Microsystems Inc.)

3) some test class files has different binary content but binary
equivalence is not important for them as we dont ship them. Test jar has
some new class files most likely from junit ignoring this one as well.

4) src.jar now contains package.html included as well ( not intentional,
but not problem either so ignoring it)

5) tar and zip tasks are not part of the build, but can be requested
explicility. The contents of tar and zip are going to be little different
than previous but serves the purpose so we can live with it.
Bug fix: Update routing strategy for all stores in case of update store definitions operation
Adding client operation during AdminService tests to catch any side effects of the admin operation
Preparing to release 1.8.2 with the split stores xml fix
check metadata incorrect results, hard analysis

Fix the new admin metadata check command and did the same change
for old admin command.

1) If check metadata fails it says true or false but not the
  actual failure.
2) Check metadata sometimes incorrectly reports failure depending
   on the order in which stores are returned.
3) Check metadata will reprot success if a store is completely missing
   from one of the nodes. It does not track number of times retrieved.

With this commit the check metadata is done using a map.

For stores check
The map will be from storeName to (map from store defintion
to nodeName)

for other
The map will be from object of that key to nodename.

This map will be used for consistency check. This map will group non
matching information to groups for easier analysis. The lenght of the
value in the map will be evaluated for missing information, solving the
problem 2 and 3 listed above
[python client] Fixed reconnect in _execute_request
Merge pull request #179 from mojn/reconnect-bugfix

[python client] Fixed reconnect in _execute_request
Merge pull request #178 from arunthirupathi/checkMetadata

check metadata incorrect results, hard analysis