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