ddl: Do not succee the last_gc_safepoint when physically dropping table is skipped

[JaySon-Huang]

What problem does this PR solve?

Issue Number: close #8911

Problem Summary:
In #8721, we introduce a rule that: "if the regions of a given table is not totally removed from TiFlash, skip physically dropping it". However, it does not set the succeeded = false, so after all it will update the last_gc_safepoint.
When the whole cluster has few write commands, the gc_safepoint may not change. It make that the physically dropping only run after the gc_safepoint is changed again. Which will slow down the data disk reclaim.

What is changed and how it works?

• If physically dropping a table is skipped by regions are not totally removed, set succeeded = false
• Then the last_gc_safepoint will not get updated
• And after ddl_sync_interval_seconds passed, SchemaSyncService::gc will run again even if the gc_safepoint on PD side is not changed

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None

[JaySon-Huang]

/run-all-tests

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JinheLin, Lloyd-Pottiger

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JinheLin,Lloyd-Pottiger]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-04-08 10:37:24.3962673 +0000 UTC m=+872305.923807846: ☑️ agreed by JinheLin.
• 2024-04-08 12:36:35.678478943 +0000 UTC m=+879457.206019489: ☑️ agreed by Lloyd-Pottiger.

[ti-chi-bot]

@JaySon-Huang: Your PR was out of date, I have automatically updated it for you.

At the same time I will also trigger all tests for you:

/run-all-tests

trigger some heavy tests which will not run always when PR updated.

If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.5: #8913.

[ti-chi-bot]

In response to a cherrypick label: new pull request could not be created: failed to create pull request against pingcap/tiflash#release-8.1 from head ti-chi-bot:cherry-pick-8910-to-release-8.1: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between pingcap:release-8.1 and ti-chi-bot:cherry-pick-8910-to-release-8.1"}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request"}