enh(updatenotification): Try to make legacy-notification smart(er)

[joshtrichards]

• Resolves: Fix or retire legacy notifications in the Updater to avoid constant updater notifications if the Notifications app is disabled #43645

Summary

If updatenotification app is enabled (the default), but the notifications (push notifications) app is disabled, we load a so-called legacy-notification as a toast message as a fallback to inform admins about new available updates. If there is a new version of Server available, a new toast is generated upon every DOM reload. An admin (effectively) can't dismiss it:

If a user that disables push notifications still wishes to periodically be notified in the Web UI about new updates they must tolerate the constant toasts all day long every day without the ability to dismiss them beyond the next page load.

Example: Joe User is happily running Server v27, but doesn't plan to update to v28 soon. They don't want to be told about the latest v28 release all day long every day long in a new toast.

Alternatives from the user's perspective:

• Re-enable the notifications app even if they won't really want to
• Don't use an account with admin privileges for everyday work
• Decide it's not worth it and disable all update notifications (by either disabling the updatenotification app outright or setting updatechecker: false in config.php) [likely not an action we want to encourage if it's merely out of frustration with the constant toasts]

This PR tries to make this legacy code a tiny bit smart, by only sending the notification one day a week and on the half hour only.

Currently it's set to every 7th day, but maybe every 4th or something makes more sense (in order to be less likely to skip a weekday/etc.).

Keep in mind this doesn't have to be perfect. It's already only a fallback that is only utilized when the notifications app is disabled.

TODO

• Confirm hard coded every X day makes sense

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)