fix: avoid infinite recursion of openedx-event

[Ian2012]

Description: This PR adds a new argument from_event_bus to the send_event method (and related ones) that allows marking a Django signal as already processed from the event bus and avoids infinite emission of the same signal if such signal is consumed in the same runtime.

The following code block must be used on the consumer to avoid processing the signal in the same process that emitted the signal:

from openedx_events.tooling import SIGNAL_PROCESSED_FROM_EVENT_BUS

...

def my_signal(...):
    if not kwargs.get(SIGNAL_PROCESSED_FROM_EVENT_BUS, False):
        logger.info("Event received from a non-event bus backend, skipping...")
        return

This has been tested with the event-bus-redis without any changes as the behavior of calling send_event_with_custom_metadata is to enable the from_event_bus param. Tested on https://github.com/openedx/event-routing-backends/pull/361 with the signal emitted on https://github.com/openedx/event-tracking/pull/246

ISSUE: Solves: https://github.com/openedx/openedx-events/issues/79

Testing instructions:

Merge checklist:

• [ ] All reviewers approved
• [ ] CI build is green
• [ ] Version bumped
• [ ] Changelog record added
• [ ] Documentation updated (not only docstrings)
• [ ] Commits are squashed

Post merge:

• [ ] Create a tag
• [ ] Check new version is pushed to PyPI after tag-triggered build is finished.
• [ ] Delete working branch (if not needed anymore)

Author concerns: List any concerns about this PR - inelegant solutions, hacks, quick-and-dirty implementations, concerns about migrations, etc.

[openedx-webhooks]

Thanks for the pull request, @Ian2012! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[mariajgrimaldi]

The next release with these changes will affect the event bus implementation tooling, so I'm pinging @robrap @timmc-edx so they know. Thanks!

[Ian2012]

The next release with these changes will affect the event bus implementation tooling, so I'm pinging @robrap @timmc-edx so they know. Thanks!

@mariajgrimaldi it will not affect them as event-bus-redis and event-bus-kafka already call send_event_with_custom_metadata on receiving signals from the event bus. There doesn't exist a signal that is produced/consumed on the same runtime (except this current work: https://github.com/openedx/event-routing-backends/pull/361) and this PR makes the default behavior to mark the signal when calling such a method.

[Ian2012]

@timmc-edx rebased and bumped. Do you think is ready to be merged? cc @mariajgrimaldi

[openedx-webhooks]

@Ian2012 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.