Fix Redispatch method of Redispatcher

[Shaddoll]

What changed?

• Update redispatcher to use 1 priority queue to store tasks
• Fix Redispatch method to redispatch the given number of tasks immediately

Why?

• Redispatcher redispatches tasks based on redispatch time, it's unnecessary to store tasks in separate priority queues. Getting rid of the priority queue map can reduce the complexity of the codebase.
• The original implementation of Redispatch method doesn't redispatch the target number of tasks immediately, and the target size is not used as expected.

How did you test it?
unit tests

Potential risks
Redispatcher might be broken

Release notes

Documentation Changes

[taylanisikdemir]

Can the Redispatch() function call this redispatchTasks()? The logic looks similar except:

• Redispatch() caps it to targetSize
• redispatchTasks() updates item.redispatchTime
• redispatchTasks() updates timer gate

Are these differences intentional? Even if some of them are intentional, we can make those configurable and still have a single task redispatch function doing all this to avoid redundancy

[davidporter-id-au]

+1

[davidporter-id-au]

so, I guess the plan for those tasks that couldn't be submitted is to rely on the redispatch timer?

The core semantic change - as I understand it - is that you're making a function that may fail to redispatch the tasks via the async loop, but then puts it in a in-memory queue for redispatch next tick?

that seems reasonble, but just making sure I'm following.