[SPARK-34518][SQL] Rename AlterTableRecoverPartitionsCommand to RepairTableCommand

[MaxGekk]

What changes were proposed in this pull request?

Rename the execution node AlterTableRecoverPartitionsCommand for the commands:

• MSCK REPAIR TABLE table [{ADD|DROP|SYNC} PARTITIONS]
• ALTER TABLE table RECOVER PARTITIONS

to RepairTableCommand.

Why are the changes needed?

1. After the PR [SPARK-31891][SQL] Support MSCK REPAIR TABLE .. [{ADD|DROP|SYNC} PARTITIONS] #31499, ALTER TABLE table RECOVER PARTITIONS is equal to MSCK REPAIR TABLE table ADD PARTITIONS. And mapping of the generic command MSCK REPAIR TABLE to the more specific execution node AlterTableRecoverPartitionsCommand can confuse devs in the future.
2. ALTER TABLE table RECOVER PARTITIONS does not support any options/extensions. So, additional parameters enableAddPartitions and enableDropPartitions in AlterTableRecoverPartitionsCommand confuse as well.

Does this PR introduce any user-facing change?

No because this is internal API.

How was this patch tested?

By running the existing test suites:

$ build/sbt -Phive-2.3 -Phive-thriftserver "test:testOnly *AlterTableRecoverPartitionsSuite"
$ build/sbt "test:testOnly *AlterTableRecoverPartitionsParserSuite"
$ build/sbt -Phive-2.3 -Phive-thriftserver "test:testOnly *MsckRepairTableSuite"
$ build/sbt "test:testOnly *MsckRepairTableParserSuite"

[SparkQA]

Test build #135413 has finished for PR 31635 at commit 1336293.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[MaxGekk]

@dongjoon-hyun @cloud-fan @HyukjinKwon Are you ok with the renaming?

[cloud-fan]

I'm a bit reluctant to rename v1 commands, as they are legacy and have been there for many years.

[MaxGekk]

Sure, but this is non-public API. We have already extended AlterTableRecoverPartitionsCommand in #31499. After that, it became incompatible by sources and binary with the previous version.

[MaxGekk]

And how about the logical nodes that were massively replaced in https://issues.apache.org/jira/browse/SPARK-29900. They are legacy and have been there for many years too, aren't they?

[HyukjinKwon]

I think the point is that we might better focus on checking V2 instead of V1 commands because eventually V2 commands should replace V1 commands in the future. If this is likely only the one, I think it's fine. If there are a lot of such instances, I wouldn't change for now.

[MaxGekk]

If this is likely only the one, I think it's fine.

Yep, only this for now.

[HyukjinKwon]

I'm okay with this but let me leave it to @cloud-fan.

[cloud-fan]

thanks, merging to master!

[dongjoon-hyun]

+1, LGTM.