Use the same shared FileSystem instance across calls in HadoopTableOperations

[mccheah]

Closes Netflix/iceberg#92.

[danielcweeks]

@mccheah I'm not clear on the value of this change. The file system instance will actually get reused because it's cached at the FileSystem level (https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java#L156).

I really don't have a strong opinion for either implementation. @rdblue thoughts?

[mccheah]

The rationale is explained in the issue that was in the previous repository. See Netflix/iceberg#92 and Netflix/iceberg#91.

[mccheah]

I'm also very much averse to JVM-wide caching, as FileSystem.get does.

[rdblue]

Sorry, I reviewed the copy of this in the Netflix repo: Netflix/iceberg#108

Overall, the change is okay. I think it is fine to expose the factory method as long as it is package-private and only used by HadoopTableOperations. But that really limits the utility of it, while going against best practices for using the Hadoop FS API.

I think the best option for the use case is to subclass HadoopTables & HadoopTableOperations and replace the current behavior if you need to.

[mccheah]

A compromise could be to have HadoopTableOperations have an overridable method like so:

FileSystem getFileSystem(Path path, Configuration conf);

The default implementation can just call Util.getFs, but overriding this can run their own caching layer.

[mccheah]

Suggested the above in #13. If we prefer that, we can close this.

[mccheah]

Closing in favor of #15 .