fix wrong space key after dropping hosts

[liwenhui-soul]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

Description:

How do you solve it?

Special notes for your reviewer, ex. impact of this fix, design document, etc:

Checklist:

Tests:

• Unit test(positive and negative cases)
• Function test
• Performance test
• N/A

Affects:

• Documentation affected (Please add the label if documentation needs to be modified.)
• Incompatibility (If it breaks the compatibility, please describe it and add the label.）
• If it's needed to cherry-pick (If cherry-pick to some branches is required, please label the destination version(s).)
• Performance impacted: Consumes more CPU/Memory

Release notes:

Please confirm whether to be reflected in release notes and how to describe:

ex. Fixed the bug .....

[critical27]

Do we support drop several hosts at the same time?

Suppose we have a space s1 with only one replica on [z1, z2, z3], each zone has one host, which is [h1, h2, h3]. If we execute DROP HOST h2, h3, base on current implementation, s1's zone list would be either [z1, z2] or [z1, z3], not [z1]. The reason is that checkRelatedSpaceAndCollect is modify the zone list based on data in rocksdb....

That's why we need spaceMap. Correct me if I am wrong....

And we'd better add a test case in TCK later

[HarrisChu]

Do we support drop several hosts at the same time?

yes, support

[liwenhui-soul]

Do we support drop several hosts at the same time?

Suppose we have a space s1 with only one replica on [z1, z2, z3], each zone has one host, which is [h1, h2, h3]. If we execute DROP HOST h2, h3, base on current implementation, s1's zone list would be either [z1, z2] or [z1, z3], not [z1]. The reason is that checkRelatedSpaceAndCollect is modify the zone list based on data in rocksdb....

That's why we need spaceMap. Correct me if I am wrong....

And we'd better add a test case in TCK later

fixed

[critical27]

LGTM