This should prevent the issues we've seen recently where cms modules are
imported by the running lms process, resulting in two celery instances
being created and tasks intermittently being registered to the wrong
instance (and therefore effectively lost.)
In commit ab6bf348d4/PR #25822 we tried to ensure that only one or the
other of the instances was created by adding a startup check.
Unfortunately, there's an external shared library that refers directly
to the lms celery, causing a startup failure in cms, so we had to revert
it. Rather than waiting to fix that library, this commit collapses
the two instances together so that there is only ever one.
Ticket: BOM-2086
Currently there are parts of the LMS that import content from the CMS
APP and vice-versa. When this happens, we end up with 2 instances of
the celery app and some tasks get registered to the wrong one. The
tasks that were getting registered to the wrong one are never able to
run and result in lots of production errors on celery workers.
The timing of the CMS celery app instantiation is non deterministic
so different tasks get lost depending on when it's imported by some
code in the LMS.
As long as SERVICE_VARIANT is set, this code should prevent the
instantiation of both celery apps.
We monkey patch Kombu's entrypoints listing because scanning through
this accounts for the majority of LMS/Studio startup time for tests,
and we don't use custom Kombu serializers (which is what this is for).
Still, this is pretty evil, and should be taken out when we update
Celery to the next version where it looks like this method of custom
serialization has been removed.
FWIW, this is identical behavior to what happens in Kombu if
pkg_resources isn't available.
