There are multiple reasons why we might not want to make a specific event type visible in the Drawer:

• If the events contain sensitive information (security, CVE...), the list of Drawer recipients needs to be restricted - To be implemented with Kessel at a later stage.
• The payloads we receive from some tenants may require significant transformation before they can be included in the Drawer (e.g. OCM). Until that's done, we don't want to include them in the Drawer.
• When a new tenant onboard Notifications, we might want to work on the Drawer template and validate it before making it visible to customers.

Acceptance criteria:

• A new "include_in_drawer" (name to be discussed) boolean field is added to the Event Type schema in the DB.
• The boolean field is set to false by default, meaning we're not exposing any Event Types in the Drawer automatically and making a manual decision for that.
• The same field is added to the EventType JPA entity in the codebase.
• The field value can be modified from the internal REST API and from the Admin UI (checkbox while editing an Event Type). Updating the Admin UI is considered optional in this ticket. If that helps, this could be done with a follow-up ticket.
• The field is covered by unit testing as well as IQE testing.
• In the DrawerProcessor class, an early exit is added to the "process" method if the type from the processed event should not be included in the Drawer.
• The DrawerProcessor tests are updated accordingly.
• The DB schema update and the code changes must be shipped in separate releases to prevent Kafka processing failures.