feat: refactor reminders

[djaiss]

This PR completely refactors how reminders are managed.

• The Notification object has been completely removed.
• There are 3 tables for reminders:
  • reminders
  • reminder_outbox
  • reminder_sent
• Special Dates do not have a reminder_id column anymore
• A reminder is now only defined by an initial_date.
• A reminder in itself is not sent - once it's scheduled, we create a ReminderOutbox object that will be sent.
• Think of ReminderOutbox as the queue for reminders that need to be sent.
• A ReminderOutbox object has a nature field which can contain two values: reminder and notification. notification means that it's a reminder that needs to be sent a few days the actual reminder is sent - these correspond to the Reminder Rules set in the account.

New processes

• Once a reminder is created, we create ReminderOutbox objects
  • one of the reminder type
  • two for each reminder rules setup in the account.
• Once a reminder outbox is sent:
  • we create a new corresponding entry in the reminder_sent table and delete the Reminderoutbox object.
  • we schedule the new reminder outbox if it's a recurring reminder
  • we mark the corresponding reminder if it's a one time reminder
  • we delete the reminder outbox
• A reminder is scheduled for a specific user.
• The only cron that remains with this new system is the send:reminders command which takes care of everything.
• Special dates do not have a reminder_id anymore. It shouldn't be special dates' responsibilities to know if they have a reminder associated with them. All reminders should be linked to contacts. Therefore, we got rid of the setReminder method in the specialDate class.
• We don't store anymore on the reminders table the next expected date of the reminder - we only store the initial date, then we always calculate the next date on the fly.
• Some reminders shouldn't be deleted from the UI - for instance, reminders about birthdays. For those birthdays, we don't display the Edit and Delete buttons in the list of reminders - this is controlled by the new delible field in the reminder object.

Other changes

• Create all services for reminder management
• Add foreign keys for reminders, contacts, reminder rules, special dates

Limitations

• No API methods for managing ReminderOutbox and ReminderSent objects yet.
• Reminders that have been sent are not displayed in the UI yet.

---

• Make sure existing data is migrated

[sonarqubecloud]

SonarQube analysis found issues:
Bugs: 0
Vulnerabilities: 0
Code Smells: 18

Including the following issue(s) which could not be reported in line:

1. Code Smell: Define a constant instead of duplicating this literal "account_id" 15 times. (more)
2. Code Smell: 1 duplicated blocks of code must be removed. (more)
3. Code Smell: 1 duplicated blocks of code must be removed. (more)

See all issues in SonarCloud

[djaiss]

@asbiin ready for review 😀

[asbiin]

See my review here.
Some little change request, and questions.
Thanks @djaiss !

[asbiin]

You should use

Suggested change

	$date = Carbon::parse($data['happened_at']);
	$date = DateHelper::parseDate($data['happened_at']);

[djaiss]

No because it's Y-m-d format and this helper needs H:i:s as well. It expects DateTime and I have a Date.

[asbiin]

Nope, DateHelper::parseDateTime parse a DateTime, but DateHelper::parseDate needs a Date format, and render a Date format.

[djaiss]

ahhhh ok I get it.

Done

[github-actions]

This pull request has been automatically locked since there
has not been any recent activity after it was closed.
Please open a new issue for related bugs.