feat: support running in background (paused) state

[gustavo-bonfim]

Context

React Native has a limitation where setTimeout does not run while the app is in the "background" state (paused but not completely closed). This issue affects the task queue, causing tasks to execute only when the app returns to the "active" state.

Solution

This Pull Request adds a check for the app's state before using setTimeout. If the app is in the "background" state, the function is executed immediately, ensuring the task queue works correctly.

[SimonErm]

Hello @GustavoBonfimS,
thank you for your contribution. Is this a bugfix or feature? Do you have any reference if the background/setTimeout behaviour is a bug or feature of react-native and if it is handled the same on ios and android? It would be nice if we could document why we handle the state this way.

[gustavo-bonfim]

It's hard to say whether it's a bug or a feature; the only documentation I found was this:
https://reactnative.dev/docs/timers

However, I found people experiencing issues with timers:

• https://stackoverflow.com/questions/51997866/react-native-setinterval-getting-paused-when-app-is-in-background
• setTimeouts don't work in background message handler invertase/react-native-firebase#3955

I created a sample project to test the timers in a more isolated way:
https://github.com/GustavoBonfimS/rn-timers-test

In the tests, it was possible to identify that setInterval works differently on iOS and Android.

Android:

Teste.Android.mp4

ios:

rn-timers-test-ios.mov

My team and I faced issues with this library in the following scenario:
While the app is offline, we store request data in a queue. When the app goes back online, it should process the queue to sync the data with the server. We noticed that the jobs were not being executed due to this issue, so we applied a patch with the same changes as in this PR, and everything worked correctly. We've had this change in production for some time, and our users have not reported any problems.

I'll be willing to help with more tests.

[SimonErm]

Thank ou for the detailed description :-)
I think we should add a plattform check too if it behaves differently, so iOS can use setTimeout and android can use a fallback.
Maybe we could implement a kind of polyfill for setTimeout for android, because with the current implementation the updateInterval would be ignored if the app is in background (I think this was the reason setTimeout was used instead of a direct call, but i can't remember)