Decouple creating source file's handler with resolving as URI in ScanSourceOp

[bobbai00]

This PR refactors the logic of resolving a user-given filename.

Previous Logic and the problem

1. FileResolver.resolve not consistent across different file types

For FileResolver.resolve

• input parameter: user-given filename
• output: Either[String, DatasetFileDocument]

This logic is not consistent, as it return either a string, which is the URI of the local file, or a DatasetFileDocument, which is the fileHandle of a file in dataset.

We want to make this logic consistent, meaning that it only output one type, URI, for all kinds of files.

2. FileHandle is opened when doing setContext for ScanSourceOp, not before actually reading it

Currently for the ScanSourceOpDesc, the setContext function opens the fileHandle,

override def setContext(workflowContext: WorkflowContext): Unit = {
    super.setContext(workflowContext)

    if (fileName.isEmpty) {
      throw new RuntimeException("no input file name")
    }

    // Resolve the file and assign the result to fileHandle
    fileHandle = FileResolver.resolve(fileName.get)
  }

This is not proper, as the file is not read at this moment yet. The ScanSourceOpDesc should carry fileUri, instead of fileHandle. And when doing inferSchema, or OpExec executing, will the fileHandle be created.

New Logic

For problem 1, FileResolver.resolve will return URI instead of FileHandle

For problem 2,

• FileResolve.open will return the FileHandle
• ScanSourceOpDesc change the fileHandle: FileHandle to fileUri: String
• A new method LogicalPlan.resolveScanSourceOpFileName is added to resolving user-given filenames to URI, this method will be called when doing workflow compilation
• fileHandle will be created by FileResolve.open right before the inferSchema and PhysicalOp executing.

[Yicong-Huang]

LGTM. left some comments. We can manage URIs as string, primitive types are more easy to use accross languages. Not very clear of the life cycle to open the file: 1) given a resolved URI, can we open the file (either local or remote) with new File(resolvedUri)? if so maybe we don't need the FileHandle class and we can use standard File object? 2) no matter if we are managing FileHandle or using standard File object, please make sure the opened files are closed properly.

[Yicong-Huang]

LGTM!