Split out new classes - delayer, blocker, and queuer

[AlanCoding]

Please confirm the following

• I agree to follow this project's code of conduct.
• I have checked the current issues for duplicates.
• I understand that dispatcher is open source software provided for free and that I might not receive a timely response.

Feature type

New Feature

Feature Summary

The largest body of code we have is in pool.py, which is self-evident knowing the features it supports.

When the workers run out of capacity or a task is blocked, those go into WorkerPool.queued_messages. I want to re-think that statement.

Putting both blocked tasks and tasks waiting (due to lack of capacity) into the same line means that a whole new construct had to be introduced of get_unblocked_message. Say we put these into 2 different data structures:

• blocked_messages
• queued_messages

Then when capacity frees up, you are free to go from the first in the queued messages with no further questions asked. If there are none there, then you would then look in the blocked messages to see if anything has freed up.

In addition to that, the main.py has logic to support task delay. These are not held in a queue, but tasks are created for wake-up events. I have since been convinced that this would be better rewritten to create at most 1 task to support delayed tasks, see #57

This would mean that delayed tasks will be maintained in a data structure, maybe even a dequeue. So we'll call that:

• delayed_messages

Now we have 3 clearly defined data structures which are all linear moving tasks through a state diagram. Hopefully, most tasks will skip all 3 of these. All the more reason... we should separate the code for handling these from the main line of main/pool code. Because of all that, this proposes to introduce 3 new types of classes:

• DelayedManager
• BlockedManager
• QueuedManager

All 3 of these will have an internal store of tasks. The delayed manager will have a task associated, but neither of the others will.

We should have a protocol for all of these to define the interface. For this to work well with the BlockedManager, it will have to call out to the combined entity of the WorkerPool and the QueuedManager to get some generalized list of tasks which are "in-progress".

Because DelayedManager is a producer-like object, it should stay with the main.py code. The BlockedManager is the only one that is in-between, and could live with the main code or the pool code.

Steps to reproduce

N/a

Current results

No response

Sugested feature result

n/a

Additional information

No response