We run atomic-requests in almost all environments (for the lms and cms
anyway) EXCEPT devstack_with_worker. Using a different setting means
that even if you think you are testing with a worker like real deploys
use, you are not actually testing with the data a worker would
actually see.
The removed code also claims that if you run with atomic transactions
and a worker you will deadlock the system. If so edx.org would be
deadlocked at all times and yet is not. The old code was vintage 2015
and its assumptions probably haven't been examined since then.
https://github.com/openedx/edx-platform/pull/31261 fixed celery
cache behavior when not running a worker and made sure production
would keep the old cache behavior, but missed these secret alternate
settings files, bring them up to date.
Also fixes the cms file to have the actual broker URL.
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
