Dropping table data is not atomic

[JaySon-Huang]

Now table's data will be dropped after it has passed the GC time. (See SchemaSyncService::gc())
But dropping table data is not atomic. When there is a large amount of data / deployed with multi-disks, dropping a table data could cost tens of seconds. If TiFlash crashes during dropping table data, some broken data may be left on disks and make TiFlash can NOT restart normally.

Workaround:
We could see which table is broken by tracking the logfile. Ensure whether that table id is able to remove data from disks by querying TiDB. Manually remove those files left on disks.

[ilovesoup]

What is the status of this one? @JaySon-Huang @flowbehappy

[flowbehappy]

@ilovesoup We will discuss it next week.

[lidezhu]

Table is regarded to be dropped after its metafile has been removed which is atomic. And metadata is removed before remove data.
So there is just some potential that left some data on disk but tiflash can still work normally even it crashes in the process of dropping a table. No need to fix it on previous version.