Refactor to hide CapabilityService from the Pyramid request
Direct access to the CapabilityService is only warranted on one call, the run_capability call. I have separated that into a step that creates the object and another step that sends an AMQP message to begin executing that execution. This is handled by a new object in the Pyramid request, the CapabilityLauncher.
The CapabilityLauncher must share the Router with the CapabilityService, or there will be multiple readers of the same queue, and AMQP will round-robin the messages between the CapabilityService and the request-based CapabilityLauncher, which has no basis for handling the messages.
I have also made several unrelated changes here which may be worth keeping or discarding:
- Postgres server's data is now external to the container (to help with container bloat)
- Route matching is now disabled in the dev.ini (to help with reading logs)
I can walk those back pretty easily if people want, so let me know.
Edited by Daniel Lyons