1. Make max concurrency at which receptor works configurable, so we can have more deterministic relationship between a receptor instance and its resource requirements.
2. Current design of receptor runs afoul of system limits, especially in containerized environments where more strict limits may be in place. Makes receptor incompatible with setting max-pids and other ulimits on the container.
3. receptor is currently designed to turn payloads directly into cmd.exe calls, e.g. it goes as fast as it can and spawns basically unbound number of processes/threads, which in turn may open files or inherit file descriptors. This can cause receptor to fail as it hits system limitations around max pids and file descriptors. If we can configure max concurrency of receptor, and rework it so that payloads get added to some sort of queue, and once ready, picked up off the queue and executed, then we can more likely constrain the resource footprint of a given receptor deployment. This will play much nicer in containers.
4. This could impact already complicated relationship between controller's status of jobs and receptor's status of jobs. See previous issues https://issues.redhat.com/browse/AAP-1749 https://issues.redhat.com/browse/AAP-42889 https://issues.redhat.com/browse/AAP-5172  (tl;dr controller moves job into running immediately after work submit, even though not running in receptor yet)

Putting component as controller, but its really in receptor.