Issue : After the HadoopFileSystem object is created, the validity of
the fileSystem is verified by doing a sample operation. If the operation
fails the Hadoop FileSystem object is leaked. This object should be
cleaned up by the Garbage collection, but all the FileSystem objects
are cached, so this is leaked. When voldemort server is used with
secure webhdfs (swebhdfs) file system it leaks enough memory to kill
the servers eventually.

Previously in voldemort webhdfs file system handles were leaked.
Apparently webhdfs file system handles are very cheap. But in SwebHdfs
they have the security certificate embedded in them. This causes them to
be very big.

Heap Dump analysis
WebHdfsFileSystem - 3768 Objects - 80 MB
SWebHdfsFileSystem - 1748 Objects - 3 GB

Solution :
1)  Disable the caching for the following reason
 Hadoop FileSystem class caches the FileSystem objects based on
 the scheme , authority and UserGroupInformation.

 The default config was to generate new UserGroupInformation for
 each call, so the cache will be never hit. In the case where the
 FileSystem is not closed correctly, it will leak handles.

 But if the UserGroupInformation is re-used, it will cause the
 FileSystem object to be shared between HdfsFetcher /
 HdfsFailedFetchLock. Each Voldemort HdfsFetcher/HAFailedFetchLock
 lock closes the fileSystem object at the end, though others might
 still be using it. This causes random failures.

 Since it does not work in both the cases, the Caching is
 disabled. The caching should be only enabled if the
 UserGroupInformation is to be re-used and the close bug is fixed.

2) Clean up the file handles on the error cases. Traced down all the
handles and cleaned them up on the error path.