Since MDL-67494 has been reverted, we will need to think about another approach to fix the Calendar/Data request bug.

Discussing with stronk7, he suggested few ideas for the next try:

1. We try to find some better alternative to cleaning the users and fix the GDPR thing. For example, we know that we can do that with core modules. And that will help to a lot of sites.
2. We slowly go adding modifications to the calendar API to be more strict (warning about wrong / unsupported combinations).
3. Also can invent some report to look for strange calendar events that at some point, will be considered incorrect.
4. At some point in the future… the new API will stop supporting the wrong events (after long deprecation support and so on).

Steps to reproduce from MDL-67494:

Given that "Contact privacy officer" is turned on
And I log in as a teacher enrolled in Course A
And I create a course event
And I create an assignment with a due date
And I create a group event for Group A
And I go to my profile
And I click on "Delete my account"
And I submit my request
And the privacy officer approves my deletion request
When cron runs and my account gets deleted
And I log in as a student enrolled in Course A and a member of Group A
And I go to Course A's calendar
Then I should see the course event
And I should see Group A's event
And I should see the assignment's due date event
But I cannot see those events anymore because they have already been deleted.

I think that the user ID should only be set for user-type calendar events and subscriptions so these shared calendar events and subscriptions won't be tied to the user who created them. If we want to track who created the calendar event/subscription, then the logs should be able to tell us that.