[#2723] Support multiple backends for Notifications API

[pi-sigma]

Taiga: https://taiga.maykinmedia.nl/project/open-inwoner/task/2723

Related: https://taiga.maykinmedia.nl/project/open-inwoner/task/2700

Note: the notificaties.test.openzaak backend does not set an auth header when sending test notifications for newly created subscriptions, which can lead to false positive error logs when testing webhooks (cf. https://sentry.maykinmedia.nl/organizations/maykin-media/issues/363204/?project=284)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 90.33613% with 23 lines in your changes missing coverage. Please review.

Project coverage is 94.94%. Comparing base (4bc9462) to head (912095b).
Report is 4 commits behind head on develop.

Files with missing lines	Patch %	Lines
...0002_migrate_data_from_notifications_api_common.py	66.66%	15 Missing ⚠️
src/notifications/models.py	91.30%	4 Missing ⚠️
src/notifications/validators.py	88.88%	2 Missing ⚠️
src/notifications/admin.py	95.00%	1 Missing ⚠️
src/notifications/tests/utils.py	90.90%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1378      +/-   ##
===========================================
- Coverage    94.96%   94.94%   -0.03%     
===========================================
  Files         1032     1043      +11     
  Lines        37949    38290     +341     
===========================================
+ Hits         36039    36353     +314     
- Misses        1910     1937      +27     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[swrichards]

Further to my other comments: I think this needs to stay in for the moment. We really only want this to be removed once we're positive the migration has been completed.

We should check in with @sergei-maertens -- he once mentioned they had a similar issue in open form, and the solution involved using the checks framework to ensure users upgrade via a certain path (e.g., you cannot go from 1.x to 1.z without first going through 1.y). With something like that, we could enforce that the migration is run before the users upgrade to a version that drops the package.

[sergei-maertens]

This is the implementation: https://github.com/open-formulieren/open-forms/blob/a4cfd74aa47a547c7a36055daf8611af128b7bba/src/openforms/upgrades/upgrade_paths.py#L78

Next week is Open Forms off-week - I could use that time to extract this code into a re-usable django-app/package that you could then use in OIP for these kind of migrations. Would that be acceptable?

[swrichards]

This still has references to notifications_api_common, and is I think where the logic for going from a singleton to many configs would also have to be handled.

[pi-sigma]

Checked: the only lingering references to notifications_api_common are in INSTALLED_APPS, the data migration and the associated test.

I am not sure we need special logic in the NotificationsWebhookBaseView to handle different backends (in the way we need special logic to handle differen ZGW backends). We need to be able to register webhooks with different backends, but this is now possible. When a request comes in at the NotificationsWebhookBaseView, we determine the subscription from the request, create a notification from the data and pass it on to the notification handler.

[swrichards]

One nitpick, otherwise looks good to me.