Add background push-notification on Android App

[Reckless-Satoshi]

Is your feature request related to a problem? Please describe.
The Android app is torified and, while on the foreground, is continuously refreshing the current order. However, when in the background the code running in the webview pauses and the order stops refreshing.

The Android app is the perfect notification system for robosats as it is fully private and secure. Any other alternative (firebase, telegra, etc has very negative impact to privacy).

Describe the solution you'd like
Ideally, we should be able to run a background process that is not killed by Android and that will notify users on order status changes. I think react-native-background-actions and react-native-notifications might be good packages for this task.

The order is currently refreshing on our web js. This means we will probably need to move this chunk inside of a new systemClient method that fetches order status as usual if the app is ran in the browser, but instead, fetches order status from the parent react-native wrapper if the app is running within the Android webview app (and triggers the notifications if needed).

Additional context

This task is rewarded with ⚡ 800K Sats ⚡

[ghost]

Short update on notifications.

Looks like react-native-notifications doesn't support local notifications on Android - https://github.com/wix/react-native-notifications/blob/c877f54c8a8df713536479a2cdf740a11be966ce/README.md?plain=1#L38

It also looks like react-native-push-notifications isn't really maintained anymore - last commit was 2 years ago and maintainer says he has stopped.

"notifee" seems to be the new kid on the block and actively maintained so I'll be evaluating that. It has a paid for vibe but is FOSS as of September (Apache)

https://github.com/invertase/notifee

[ghost]

Update: will be using react-native-background-actions for the background order status polling.

Current thinking:

• The background service runs in its own HeadlessJS context, and the code must reside in /mobile i.e. the React Native project
• However, the polling frequencies are currently defined in frontend/src/contexts/AppContext.ts#L38
• Since an order could undergo multiple state changes while the app is backgrounded, the background service needs to be aware of the dynamic polling frequencies.
• As far as I can tell, this is the first time that logic (at the very least this table of polling constants, possibly more) needs to be shared across both the React App and the React Native subprojects
• Currently experimenting with a /shared top level folder for this purpose