Enable producing to event bus via settings

[robrap]

At this time, producing a signal to the event bus requires code. See the event bus how-to for details.

This is problematic because:

1. Nearly all openedx-events signals should be able to be produced to the event bus, and different operators may have different needs.
2. Related, for named releases, operators should be able to produce new events without changing code or waiting for the next named release.

This issue proposes to make the switch to configuring this via settings, rather than code.

Some thoughts/questions about the settings:

1. It should be possible to toggle on/off an event as we do in code. I imagine that we'd want to be able to do this without having to add/delete all config for a topic, and could instead set a flag.
2. Does the setting need to support producing the same event to multiple topics? Maybe not? I can't remember where we landed for migrations, and maybe we could add this later while keeping a simpler one-topic setup by default?
3. The settings should support multiple events going to the same topic. See this lifecycle event issue for details on where we landed on this: [Discovery] Handle multiple lifecycle events on single event bus topic #78.
4. It would be great if services could include default settings for signals that are expected to be produced. These may be toggled off, or incomplete, but could be used as documentation of what signals should be configured. (Or, someone can provide an alternative solution to this particular issue.)
5. This may be best covered in an entirely separate ticket, but it would be nice if we could toggle some sort of audit that would help estimate the data that would be sent to the event bus if a event were sent there. This could be used for making cost estimates for existing events.
6. Reminder: replace existing event producing code with this config when it is available.

[bmtcril]

@navinkarkera is going to take this on next and write an ADR up front for the proposed solution. I can't assign it to him, though. :)

[robrap]

@rgraber: Adding a reminder for https://github.com/openedx/openedx-events/pull/272/files#r1347321249, which is to not have the configs reading fail hard for a single part that is misconfigured.

• Allow partial loading of config (with proper error handling to hopefully catch what is broken).

Questions:

• Do we want to alert on this?
• Will we still raise an error (at the end)? Or rely on logs?

[rgraber]

I'm going to create a separate ticket to deal with that. Seems like it requires more discussion.

[rgraber]

Closing this and moving the other question to #280

[robrap]

I'm going to create a separate ticket to deal with that. Seems like it requires more discussion.

@rgraber: Does "that" refer to #210 (comment)?

[rgraber]

I'm going to create a separate ticket to deal with that. Seems like it requires more discussion.

@rgraber: Does "that" refer to #210 (comment)?

Yes