Make compatible with Scheduler

I took a stab at implementing support for Scheduler for event series.

I implemented support directly within the main Recurring Events module like it is the case for the integration with Migrate, Views and Fullcalendar. Another approach would be to add a new submodule like group_recurring_events_series which integrates with the Group module. I ended up with this approach as the amount and complexity of the integration is quite limited.

It is worth noting that the Scheduler configuration option "Change creation time to match the scheduled publish time" (publish_touch) will not work with event series. It will throw a hard error during cron when an event is to be published.

The option requires a setCreatedTime() method being available on the scheduled entity. Event series do not provide one at the moment. As I see it there is currently no way to prevent this option from being offered on certain entity types.

@kasperg this would be a very welcome feature for my client and I would love to help as I can. I will take some time to test your modifications. Let me know if I can do anything else

@kasperg this isn't working for me. I can set the Scheduler options for my Event Series type and make the fields appear when creating or editing an Event Series. If saving the Event Series with a "Publish on" or "Unpublish on" value, I do not see that value reflected in the EventSeries entity values. There are no "publish_on" or "unpublish_on" values. As a result, re-loading the Event Series editing form shows the "Publish on" and "Unpublish on" fields are blank again. No scheduling occurs. I am using the "default" Event Series type.

To reproduce, install Devel module and check the entity values on the Devel tab after saving an Event Series with scheduler values. You will see that no publish_on or unpublish_on values are stored.

@endless_wanderer: Thanks for taking the time to take a look at this.

Currently I have the luxury of being able to reinstall our project frequently and the new fields are added here as expected. Given your findings I assume that something needs to be done to add this support to running systems. I expect this to involve an update hook of some kind.

If someone can point me in the right direction I am willing to take another look at this.

I'm trying to make the Scheduler work with Event Series and Event Instances.
Unfortunately, the patch didn't work perfectly.

With the original code from the MR, I had to force execution of the following code:

   $scheduler_manager = \Drupal::service('scheduler.manager');
    if ($result = $scheduler_manager->entityUpdate()) {
      return t('Added Scheduler date fields to the following entity types: %updated.', [
        '%updated' => implode(', ', $result),
      ]);
    } else {
      return t('No database fields had to be added.');
    }

Even after that, when I published the Event Series using workflows, meaning that I moved to "Published" state in the workflow, the Event Series was not published as expected since the Publish On was in the future. However, all event instances were published.
In my use case (and I image that this is the most common use case):
- The event instances must inherit the Publish On and Unpublish On configuration by default and be published only when the Event Series is published.

To achieve the above:
- I extended the Scheduler to also be available on the EventInstance entity type. (added to the MR)
- I added a hook_update to execute the code I sent above (added to the MR)
- I created field inheritance with "Inherit" configuration for the "Publish On" and "Unpublish On" fields. (not yet added to the MR, if you need this, you need to do manually)

Note:
For some reason, I couldn't use the fallback approach in the field inheritance. It would be preferable for me, but I don't know where I should look and investigate why the fallback doesn't list the Publish On/Unpublish On fields in the Destination field.

We needed this integration for our project and this looks very good.

However, I would go for a submodule based approach to ensure the encapsulation and avoid possible conflicts between the different scheduler versions.

Moving to NR to get some new feedback from module's maintainers.

Opened a new MR for the submodule approach to make easier the comparison for module maintainers.