HBASE-30350 Fix stale Region-In-Transition tracker entries on region deletion

[mnpoonia]

Summary

RegionInTransitionTracker and RegionStates are two separate in-memory maps on the master that are not kept in sync automatically. Several code paths deleted a region from RegionStates directly without notifying the tracker, so a deleted region could be left behind in the tracker forever — surfacing as a permanently stuck "STUCK Region-In-Transition" warning that only clears on a full master restart (loadMeta() rebuilds the tracker from hbase:meta from scratch; a GC'd region isn't in meta, so no stale entry survives that path).

This was the root cause of a 9.8h stuck RIT incident: GCRegionProcedure deleted a no-longer-needed region from RegionStates but never told the tracker, leaving a stale entry that nothing but a restart could clear.

Fix: add AssignmentManager#deleteRegion(RegionInfo) and its plural form #deleteRegions(List<RegionInfo>) as the single sync point that updates both maps together, and route every region-deletion call site through it instead of calling RegionStates#deleteRegion(s) directly.

Confirmed live bug, reproduced end-to-end: GCRegionProcedure. Temporarily reverting its call site back to a direct RegionStates#deleteRegion() call reproduces the original incident symptom in testGCRegionProcedureRemovesStaleRegionInTransitionEntry (the tracker entry survives GC); restoring the fix makes the same test pass again.

Plausible but unconfirmed live bug: AssignmentManager#deleteTable. DeleteTableProcedure waits for RegionStates to clear RIT before calling it, but that wait only checks RegionStates, not the tracker — so it doesn't rule out a stale tracker entry, though it isn't proven reachable either.

Defensive hardening, not confirmed reachable today (the region being deleted at these sites is already untracked — either terminal/OFFLINE on a disabled table, or a non-default replica, which the tracker never tracks in the first place):

• AssignmentManagerUtil#removeNonDefaultReplicas (split/merge)
• EnableTableProcedure (replica-count-decrease cleanup)
• RestoreSnapshotProcedure#deleteRegionsFromInMemoryStates

Test plan

• testDeleteRegionRemovesStaleRegionInTransitionEntry / testDeleteRegionsRemovesStaleRegionInTransitionEntries — cover the singular/plural AssignmentManager#deleteRegion(s) sync point directly.
• testGCRegionProcedureRemovesStaleRegionInTransitionEntry — runs the real GCRegionProcedure end-to-end through the procedure executor. Verified this test fails against the pre-fix code path and passes against the fix.
• Ran TestAssignmentManager, TestAssignmentManagerUtil, TestEnableTableProcedure, TestRestoreSnapshotProcedure, and related suites — all green, no regressions.

[mnpoonia]

Looking for approvals for running the github actions workflow
@Apache9 @virajjasani

[Umeshkumar9414]

We only delete an region once it is closed. I can think of 3 scenario of region close- 1. Table disabled 2. Merge parents 3. Split parent . In all 3 cases, regions should be out of Region-In-trnasition tracker when region was getting closed so we should never need to handle it while deleteing.

I think bug here, that we need to find out, is why it was not removed from tracker while closing. I am opposed to the change in tracker when actually there is no state change.