The range-deleter executor serves its purpose of ensuring that orphaned documents get eventually deleted but is not suited for more complex use cases given the "fire and forget" way to schedule tasks and the interconnection with metadata managers .

Purpose of this ticket is to implement a RangeDeleterService that should at least fulfill the following requirements:

• Being initialized/stopped on step-up/step-down
• Keeping track of a list of ranges to be deleted and have a thread consuming it (rather than scheduling plenty of tasks on a mono-threaded executor)
• Keep track of orphaned ranges with ongoing queries, not ready to be deleted (rather than having metadata managers tracking it separately)