[CHORE](garbage_collector): remove log-only orchestrator

[rescrv]

Description of changes

Excise the HardDeleteLogOnlyGarbageCollectorOrchestrator, which was a
separate code path for hard-deleting logs of destroyed collections.
Manual GC requests now look up collection info via sysdb and feed
them into the regular GC pipeline. Collections that no longer exist
are skipped with a log message instead of being routed to a separate
orchestrator.

• Replace HashMap<CollectionUuid, DatabaseName> with
  HashSet for manual_collections since the database
  name is now looked up on demand
• Add lookup_manual_collection_to_gc to query sysdb directly
• Remove second job stream and its duplicated result processing loop
• Add test for lookup returning None after collection removal

Test plan

Locally tested gc lib + CI

Migration plan

N/A

Observability plan

N/A

Documentation Changes

N/A

Co-authored-by: AI

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[propel-code-bot]

garbage_collector: remove separate log-only orchestrator and unify manual GC path

This PR removes the dedicated HardDeleteLogOnlyGarbageCollectorOrchestrator flow and routes manual GC requests through the existing main GC pipeline. Manual requests now store only CollectionUuid values in manual_collections, and collection metadata (including database) is resolved on demand via a new lookup_manual_collection_to_gc helper that queries sysdb.

The change simplifies execution by eliminating the second job stream and duplicate result-processing loop for log-only hard delete work. If a manually requested collection no longer exists (or has invalid/multiple lookup results), it is skipped with logging instead of being routed to a separate orchestrator path. Tests were updated to reflect HashSet-based manual tracking and to verify lookup returns None after collection removal.

This summary was automatically generated by @propel-code-bot

[propel-code-bot]

Review found no issues; refactor appears sound with simplified GC flow and updated tests.

Status: No Issues Found | Risk: Low

Review Details

📁 3 files reviewed | 💬 0 comments