Discussion for FileSystem instance be per-connector or per-session

[Yohahaha]

Description

FileSystem accept config and as a singleton created at first call of FileHandleGenerator, FileHandleGenerator was hold by HiveConnector and initialize it in ctor.

HiveConnector accept static configs in its ctor, and also accept dynamic(session) configs at runtime after PR #7659. So the issue is what kind of configs should we pass to FileSystem? If FileSystem keep singleton, it need accept HiveConnector's static config for necessary initialization. If FileSystem be per-session instance, we may need move FileHandleGenerator into QueryCtx and use session config to initialize it.

I prefer make FileSystem be per-session instance, it helps to change derived class's behavior at runtime, e.g. accessing S3 with another IAM or apply optimized config without restart.

cc @mbasmanova @majetideepak @zhli1142015

[majetideepak]

@Yohahaha Thanks for opening this issue. The FileSystem API needs an overhaul. There has been a lot of confusion/bugs around getFileSystem API and the optional config. We need a cleaner API to fix this and also allow per-session config.
In the past, I felt having too many file-system instances was bad since each fs client instantiates and consumes resources (threads, buffers, etc). So keeping an instance per session might not be ideal.
My thought is to have a single file-system instance per unique config which includes credentials.
I will be adding some thoughts on the API later today.