refactor: allow procedure to acquire share lock

[WenyXu]

I hereby agree to the terms of the GreptimeDB CLA

What's changed and what's your intention?

1. Implement KeyRwLock
2. Use KeyRwLock instead of LockMap
3. Use StringKey instead of String
4. remove redundant code

Background

During reading the paper(Granularity of Locks and Degrees of Consistency in a Shared Data Base).

I realized that to acquire a lock on the subtree, there are two ways:

• Implicitly locking: Hierarchical locking, Root-to-Leaf.
• Explicitly locking: Leaf-to-Root (Locks an entire subtree is to lock each node of the subtree in leaf-to-root order)

We're stuck in the first way and always imagine we must acquire the lock in Root-to-Leaf order and need to employ something like a Hierarchical lock.

In fact, the order acquiring locks doesn't really matter in our scenario. We only have three levels, and it's enough to meet the invariant in our system if we acquire one lock on each level.

Invariant in our system

1. The same table's (different) Region migration procedures are compatible.
2. The same DB's Ops, DDL, and Region migration procedures are incompatible with one another.

Checklist

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR does not require documentation updates.

Refer to a related PR or issue link (optional)

#2700

[codecov]

Codecov Report

Attention: 12 lines in your changes are missing coverage. Please review.

Comparison is base (6070e88) 85.45% compared to head (cfc3fb1) 85.17%.
Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3061      +/-   ##
==========================================
- Coverage   85.45%   85.17%   -0.29%     
==========================================
  Files         799      805       +6     
  Lines      129155   130891    +1736     
==========================================
+ Hits       110373   111481    +1108     
- Misses      18782    19410     +628     

[MichaelScofield]

That paper is inspiring, maybe we need to adopt the whole idea from it, including lock scheduler and deadlock detection.

[WenyXu]

That paper is inspiring, maybe we need to adopt the whole idea from it, including lock scheduler and deadlock detection.

For deadlock detection, we now simply acquire all locks in the lexicographical order. I think it enough for now. cc @evenyag @fengjiachun

[WenyXu]

@evenyag @MichaelScofield @fengys1996 @fengjiachun PTAL

[fengjiachun]

LGTM

[evenyag]

Rest LGTM