cherry-pick #2170 to release-4.0
You can switch your code base to this Pull Request by using git-extras:

# In tics repo:
git pr https://github.com/pingcap/tics/pull/2183

After apply modifications, you can push your change to this PR via:

git push git@github.com:ti-srebot/tics.git pr/2183:release-4.0-ec5f976a8fb8

What problem does this PR solve?

Issue Number: close #2169

Problem Summary:
In DataCompactor::migratePages, we avoid generating a PageFile that already exists, but we didn't check whether its "Legacy" mode exists or not.
https://github.com/pingcap/tics/blob/74c69fb1d35da3582cb9279ecb4d8597e4a78d00/dbms/src/Storages/Page/gc/DataCompactor.cpp#L150-L158
https://github.com/pingcap/tics/blob/74c69fb1d35da3582cb9279ecb4d8597e4a78d00/dbms/src/Storages/Page/PageStorage.cpp#L1137-L1145

For example,

1. We generate a PageFile "page_1000_1" for storing GC data
2. Then the data in "page_1000_1" have been migrated to another file, and "page_1000_1" become "legacy.page_1000_1"
3. Maybe some old files are held by snapshot for a long time, we happen to generate a PageFile "page_1000_1" again, then we have both "page_1000_1" and "legacy.page_1000_1" at the same time
4. After the "page_1000_1" generate in step 3 become useless, we want to set it to "legacy" and remove its data, but we find "legacy.page_1000_1" already exists, then it will throw an exception and stop us from GCing useless data
5. Finally, the TiFlash node will full of data in "t_{table_id}/log" (almost 1TiB in our case) and make the load balance bad between multiple TiFlash nodes

What is changed and how it works?

Check whether page file with same <id, level>, status in [Formal, Legacy] exists before generating PageFile for GC data

Related changes

• Need to cherry-pick to the release branch: 5.1, 5.0, 4.0

Check List

Tests

• Unit test

Side effects

Release note

• Fix the bug that TiFlash can not GC delta data under rare case