update_in_cache on lms worker (#12689)

This commit "undoes"a previous hotfix, and allows a cms course_publish
signal to trigger a block_structure update_course_in_cache task, which
is run on an lms worker queue.

Changes:
    -exposes ALTERNATE_QUEUE_ENVS
    -adds routing layer in celery.py
    -moves prior dev_with_worker settings file to devstack_with_worker
    -moves course_block api functionality into openedx/core/djangoapps/content/block_structure

cms/envs/devstack_with_worker.py

@@ -0,0 +1,25 @@
+"""
+This config file follows the devstack enviroment, but adds the
+requirement of a celery worker running in the background to process
+celery tasks.
+
+When testing locally, run lms/cms with this settings file as well, to test queueing
+of tasks onto the appropriate workers.
+
+In two separate processes on devstack:
+    paver devstack studio --settings=devstack_with_worker
+    ./manage.py cms celery worker --settings=devstack_with_worker
+"""
+
+# We intentionally define lots of variables that aren't used, and
+# want to import all variables from base settings files
+# pylint: disable=wildcard-import, unused-wildcard-import
+from cms.envs.devstack import *
+
+# Require a separate celery worker
+CELERY_ALWAYS_EAGER = False
+
+# Disable transaction management because we are using a worker. Views
+# that request a task and wait for the result will deadlock otherwise.
+for database_name in DATABASES:
+    DATABASES[database_name]['ATOMIC_REQUESTS'] = False