[server] Fix tableCount metric after dropping partitioned tables

[swuferhong]

Purpose

Linked issue: close #3481

processDropTable's onDeleteTable() is a no-op for partitioned tables
(their buckets live under partitionAssignments, not tableAssignments)
and they have no table-level replicas, so areAllReplicasInState is
vacuously true the moment the table enters tablesToBeDeleted. Without
an explicit trigger, resumeDeletions() runs only when some unrelated
stop-replica response piggy-backs it -- which can be never if no other
drop is in flight. The dropped table then lingers in tablesToBeDeleted
and tablePathById, inflating the tableCount gauge until something
else gets dropped.

Brief change log

Tests

API and Format

Documentation

[wuchong]

We should reverse the lookup by iterating over tablesToBeDeleted and checking for existence in context.allTables(). If a match is found, decrement tableSize. This approach significantly improves performance.

Set<Long> allTables = context.allTables().keySet();
int tableCount = allTables.size();
for (Long toDelete : context.getTablesToBeDeleted()) {
    if (allTables.contains(toDelete)) {
        tableCount--;
    }
}

[wuchong]

I pushed a commit to fix this comment. Please take another look.