This is two lines of thought combined into one merge:

1. AMQP clients should either receive messages or send messages
2. Capability queues are based on a database-backed queue manager rather than keeping state in-memory

Most of the work relating to the first idea comes in refactoring the Router to not be a message sender. Many places in the code now either instantiate a MessageSender instead, or use both a Router and a MessageSender if they truly needed both functionalities. The previous implementation appears to have caused messages to arrive out of order because facilities like `wf_monitor` that only send messages were also trying to receive messages, and either not handling them at all or putting them into a buffer of some kind to be dropped on the floor when the process ended.

The work relating to the second idea changes the way that steps are processed in the capability service and eliminates the capability engine concept. Now when PrepareAndRunWorkflow steps are reached, the capability is simply moved into the Waiting state and the queue manager is signaled. Whenever the queue manager is awakened, it checks to see if any queues have slots available and requests waiting. If they do, the number of available slots are used to get requests and start executing them. When an execution exits the cluster, the queue manager is signaled again, so the process continues until all the jobs are processed. As a stability benefit, we check this on startup as well.

Charlotte Hausman authored 4 years ago and Nathan Hertz committed 4 years ago

Messaging system is now running on a more robust foundation:
- `kombu` package for AMQP networking
- New Messenger and Router objects
- New message format
- Easy-to-use callback subscribing
- Can now get messages anywhere in the system easily and send replies back easily

conflicts and circular imports

Hopefully final changes to setup.py files regarding package name changes; renamed a amqp_helpers dir to channels

Made amqp_helpers directory structure match the other subprojects. Made some small changes to monitor.py and test_monitor.py

SSA-6324: tests pass when run locally; some fail in Docker container. Committing what I've got so as not to lose it after tearing my hair out for a day and a half.

SSA-6324: pytest on datafetcher_test.py executes in a Docker container. capo properties file is copied to the docker build directory, then deleted.

Tests all succeed when executed in IJ.

master: reorganized datafetcher "SDM-only" functionality removed. All tests pass, including those that launch DF from a process to simulate command-line execution. TODO: actual command line, as below, should work but doesn't yet:

datafetcher --profile local --output-dir ~/Downloads --product-locator uid://evla/execblock/93e1c0cd-76de-4e65-a3f2-d5fe55f386d8 --verbose

Pylint also finds some errors, the consequence of fixing which puts red ink in the IJ editor and causes the above-mentioned command-line tests to fail.