Current observations

The general logic that triggers the desktop notifications is pretty stable now. However, there are some issues with mobile devices, that are currently unsolved.

iOS

• iOS 16 or greater is required, as the Notification API only got introduced with Safari (iOS) 16.4.
• A web application is only allowed to make use of the Notification API if it's being run as a home-screen application (share -> add to home-screen).
• The logic itself works fine for as long as the home-screen application stays active.
• Leaving the application or locking the phone results in the operating system (iOS) freezing the browser activities after a short amount of time (around 5 seconds).
  This behaviour kills all external connections while not running any browser logic, which causes some unwanted issues.
• After unlocking the phone or by going back to the home-screen application, the browser itself gets unfreezed, which causes the tabs and web workers to continue their workflows.
• The event-stream should normally reconnect once it looses its connection (see second to last paragraph). This won't happen as it's proxied by the service worker, which itself pipes the proper event-stream from the daemon back to the tab. During the freeze phase, this connection gets dropped and the stream stays empty and locked (only an assumption, it's not possible to remote debug service workers on iOS).

This results in the app stopping to show notifications after the home-screen application was put into background or if the phone got locked.

Android

• Untested

Possible fix?

One way around this problem, albeit being a real ugly one, would be to start a freshness timer in the service worker context once the tab gets the visiblestate event fired with a value of hidden. This event is always fired once the browser stops rendering a tab, even on mobile phones and even when putting a PWA into the background or locking the screen.
As the service worker is going to get freezed as well, the freshness checks will get delayed. Once it unfreezes again, it continues with its freshness checks but notices a time delay from the last check to the current.
This could then in return trigger a reconnection on the tabs and the whole feature would continue to work. The repeating freshness checks could then be stopped as the visibilitychange event would be retriggered with a value of visible.

@raviks789

So far looks good to me.

As it seems like you're fine with the changes that I implemented, you might want to approve your review. It still needs the approval of @sukhwinder33445 and @nilmerg either way.
Thanks!