feat(dav): add webhook compatibility for calendar object events

[edward-ly]

Summary

Adds webhook compatibility to events related to calendar objects (e.g. calendar events) via implementation of OCP\EventDispatcher\IWebhookCompatibleEvent.

TODO

• Add new events to webhook listeners manual page
• (possibly others, let me know if I'm missing anything)

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[ChristophWurst]

Is this going to be a public API?

The events are in OCA, not OCP. There are no compatibility or stability guarantees in private app namespaces.

[edward-ly]

Is this going to be a public API?

The events are in OCA, not OCP. There are no compatibility or stability guarantees in private app namespaces.

Ah right, I forgot about that. So if webhooks can only listen to events in the public namespace, would adding a new namespace such as OCP\Calendar\Events and creating new events that extend the private ones be a viable solution?

EDIT: actually, in the webhook listeners documentation, there are some webhook events that are still in the OCA namespace, so I'm not sure if the workaround is really necessary.

[ChristophWurst]

EDIT: actually, in the webhook listeners documentation, there are some webhook events that are still in the OCA namespace, so I'm not sure if the workaround is really necessary.

That is true and worrying to me, but on the other hand not my responsibility.

For caldav and carddav I will require a strict separation of private and public API, so we can continue to make easy modifications to internals, and have a solid, stable API for selected classes.

So yes, if these events are consumed by other apps, please move them to OCP. Do not extend private types from the public API. Just move them.

[ChristophWurst]

See above. The goal of this PR is to expose a public API, which internal events aren't.

Thanks you for you contribution

[AndyScherzinger]

/backport to stable31

[ChristophWurst]

@AndyScherzinger are we backporting new APIs for this?

[AndyScherzinger]

In this case yes, else the customer needs to wait until v32 enterprise.