Fixed deadlock problem caused by concurrent auto create schema and delete database

[OneSizeFitsQuorum]

No description provided.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 43.43%. Comparing base (3cca91d) to head (a8c80a4).

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #12489      +/-   ##
============================================
- Coverage     43.45%   43.43%   -0.03%     
  Complexity       69       69              
============================================
  Files          3109     3109              
  Lines        192931   192931              
  Branches      22971    22971              
============================================
- Hits          83835    83791      -44     
- Misses       109096   109140      +44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[CRZbulabula]

LGTM!

[CRZbulabula]

After detail analysis, the process of producing deadlock is as follows:

1. The PartitionFetcher requires a read lock for SchemaRegions when create database.
2. The DeleteDatabaseProcedure requires a write lock for SchemaRegions when delete database.
3. Both create and delete database process are serialized.

Therefore, the DeleteDatabaseProcedure would never obtain the write lock for SchemaRegions when the read lock is already took by PartitionFetcher.

Our solution is to decompose the serialization of create and delete database interfaces. Thus, the DeleteDatabaseProcedure could obtain the write lock after the creation process finish. We've checked the code to ensure that there are no severe parallel bugs after we cancel the serializition