Change requestAnimationFrame flush condition

[bartlomiejbloniarz]

Summary

Currently we schedulerAF flush when the first callback is added to the list. However the flush method can also be called by an event, meaning that sometimes we have a flush scheduled to run on a given frame, but the callbacks array is empty. If then, another callback is requested, the array will contain 1 element, triggering another flush request (even though one is already scheduled). To prevent this, from causing countless requests on a singe frame we check the frame timestamp and abort if it's repeated.

This approach unfortunately causes some problems when video is playing in the app. On iPhone devices sometimes the displayLink can fire its callback twice in a single frame (with the same timestamp). This leads to us cancelling the rAF flush, which means that until an event triggers a flush, none updates from reanimated will come through.

This PR changes the way we request a flush. Instead of checking the callbacks array size, we instead remember whether a flush was requested and request a new one only when there was no request. This prevents us from requesting unnecessary flushes when an event has caused the callbacks array to be emptied, while also allowing for repeated frame timestamps.

closes #6371

Test plan

Check for regressions in the example app and in this example:
https://gist.github.com/kmagiera/b2df85f9512951f5e6ceee7bc569f5f1

[kmagiera]

This looks good. The only thing I'm wondering now is that when duplicated rAFs come at the same timestamp, we will run all the mappers twice with the same input, which may not be as efficient as needed, especially given it happens for example when video is being played (relatively heavy task as well). Normally, I wouldn't be concerned about running mappers twice in a frame from time to time, but it it happens continuously for the whole duration of the video, I'd love if we try to measure the consequences here and at least add a comment about that in the PR description.

[bartlomiejbloniarz]

In my testing it wasn't a continuous issue, it only happened from time to time. Sometimes I had to try for a few minutes to get it to break.

[tjzel]