[Subtask]: Optimizations and troubleshooting for the Master-Slave mode.

[wardlican]

Why are the changes needed?

Close #4171 .

Brief change log

1. For existing historical tables, if Master-Slave mode is enabled, a bucket_id must be assigned to them.
2. Fixed an issue where concurrent addition of new tables could result in multiple tables being assigned the same bucket_id, leading to bucket imbalance.
3. Fixed an issue in Master-Slave mode where the -msm flag was not passed during the optimizer's startup.
4. Fixed an issue where tables were erroneously deleted following a migration.

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible

• Add screenshots for manual tests if appropriate

• Run test locally before making a pull request

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[czy006]

Offline nodes with missing last_update_time may never be reclaimed

In AmsAssignService.detectNodeChanges (around lines 528-545), a node is marked offline only when lastUpdateTime > 0 && (currentTime - lastUpdateTime) > nodeOfflineTimeoutMs.

However, both DBBucketAssignStore#getLastUpdateTime and ZkBucketAssignStore#getLastUpdateTime return 0 when the timestamp is missing. In that case, a node that is already absent from the alive-node list will never enter the offline branch, so its buckets are never redistributed. This can leave bucket ownership stranded and prevent load recovery.

Treat lastUpdateTime <= 0 as an offline-eligible case when the node is not in aliveNodeKeys, and reclaim buckets directly; or Keep a short grace period, but after the grace period, force offline even if timestamp is missing.

[wardlican]

Offline nodes with missing last_update_time may never be reclaimed

In AmsAssignService.detectNodeChanges (around lines 528-545), a node is marked offline only when lastUpdateTime > 0 && (currentTime - lastUpdateTime) > nodeOfflineTimeoutMs.

However, both DBBucketAssignStore#getLastUpdateTime and ZkBucketAssignStore#getLastUpdateTime return 0 when the timestamp is missing. In that case, a node that is already absent from the alive-node list will never enter the offline branch, so its buckets are never redistributed. This can leave bucket ownership stranded and prevent load recovery.

Treat lastUpdateTime <= 0 as an offline-eligible case when the node is not in aliveNodeKeys, and reclaim buckets directly; or Keep a short grace period, but after the grace period, force offline even if timestamp is missing.

Okay, I will fix this issue.

[czy006]

LGTM