Notifications fines par rendez-vous (1/N): Modèle et logique

Created by: n-b

refs #1617 (closed), reprise de #1742

Fait dans cette PR:

• Renommage et refactor des “services” de notification. C’est sans lien direct avec le problème, si ce n’est que ce sont les mêmes fichiers. Au passage, je transforme Notifications::Rdv::BaseServiceConcern en véritable classe intermédiaire; je ne tiens pas à l’héritage, mais on avait déjà cette hiérarchie dans les faits, sans le dire. Pour cette raison, la PR est un peu grosse, mais ça se lit bien commit par commit.
• Nouveaux flags send_lifecycle_notifications et send_reminder_notification sur RdvUser, avec migration des anciennes données. Ces flags sont non-null en base.
• Affectation automatique de la valeur des flags à la création d’un Rdv à partir du visibility_type du Motif.
• Prise en compte des flags dans les services de notification.

Reste à faire dans les PR suivantes:

1. Choix par l’agent à la création du Rdv
2. Affichage des valeurs des flags dans rdv#show et rdv#edit

Et éventuellement:

• Je renommerais bien RdvUser en Participation ou UserParticipation, qu’en pensez-vous?
• Ça simplifierait l’évolution à venir sur les notifications multiples et les usagers simples “observateurs” d’un Rdv (#1670) On rajouterait alors un flag à UserParticipation pour indiquer si l’usager est convoqué au Rdv, et on n’aurait plus besoin de se baser sur la relation de responsable.

Checklist avant review:

• reparcourir le code rapidement pour voir les problèmes évidents (fichiers touchés inutilement, debug logs qui trainent…).
• Tester la fonctionnalité sur la review app