Collections API: Rework Celery task submission

[mmcfarland]

We rely heavily on querying Celery for a list of valid workers, one of which we use for a routing_key to keep jobs executing on the same worker, since the async SJS needed to be polled from the same worker who submitted the job. With that element removed and the GeoTrellis call converted to a synchronous call ( #2102 ) we can remove that limitation.

The same technique is used to ensure that during a release, the stack color of the dark stack does not get selected to process tasks from the live production site. We'll have to preserve this method without relying on celery.current_app.control.inspect().ping() - presumably the stack color itself can be used as a routing_key to ensure dark stack workers keep tasks within their group.

The goal in removing the current workflow is to alleviate the latency it introduces as detailed in #1894

[hectcastro]

I think that we can remove the custom routing_key stuff at all of the call sites with something like:

CELERY_DEFAULT_QUEUE = STACK_COLOR
CELERY_DEFAULT_ROUTING_KEY = "task.%s" % STACK_COLOR

Testing that things are working properly may require adding another worker block to the Vagrantfile.