[Spark] Harmonize path-based Delta table resolution

[ryan-johnson-databricks]

Which Delta project/connector is this regarding?

• Spark
• Standalone
• Flink
• Kernel
• Other (fill in here)

Description

Historically, path-based table resolution logic has been scattered all over Delta's code base. We can build on recent code improvements to start harmonizing and centralizing that logic in DeltaTableV2, which already plays a central role in all table resolution. Future changes can continue building on this base.

How was this patch tested?

Existing unit tests.

Does this PR introduce any user-facing changes?

No.

[ryan-johnson-databricks]

Something went wrong:

[info] *** 4 TESTS FAILED ***
[error] Failed: Total 6393, Failed 4, Errors 0, Passed 6389, Ignored 2749
[error] Failed tests:
[error] 	org.apache.spark.sql.delta.CloneTableScalaDeletionVectorSuite
[error] 	io.delta.tables.DeltaTableHadoopOptionsSuite
[error] 	org.apache.spark.sql.delta.RestoreTableSQLSuite
[error] 	org.apache.spark.sql.delta.CloneTableSQLSuite

(hopefully it's just test error message changes or something simple... will dig tomorrow)

[felipepessoto]

@ryan-johnson-databricks I'm wondering if you know any reason to don't support relative path, do you?

Context: #555

[ryan-johnson-databricks]

@ryan-johnson-databricks I'm wondering if you know any reason to don't support relative path, do you?

Context: #555

Replied on the ticket -- AFAIK it's because the leading / disambiguates the grammar. Also, I've seen way too many cases where people mixed up their strings, and passed a relative path as if it were an identifier (when writing, so it "works" but is actually wrong), or passed an identifier as if it were a relative path to e.g. DeltaLog.forTable (which "works" but again puts the table in the wrong place).