macOS + Node server: Latency with high polling rate devices

[m-damien]

With libpointing's new nodejs binding on macOS, devices with high polling rate (i.e. > 125Hz) "lag": the js client receives the reports much later than it should, creating a very high latency.

After some digging, it seems to be related to the cohabitation of the Cocoa's event loop with Node's main loop. Long story short: Node does not process all macOS events in its main loop and therefore HID callbacks are never called. libpointing solves this problem by processing macOS events every tick for Xms (see https://github.com/INRIA/libpointing/blob/master/bindings/Node/libpointing/pointing/pointing.cc#L30, the time given to macOS event processing was recently reduced in 11bb753). This solution is basically a trade-off: if we give more time to process macOS events, then JS events are not treated as quickly and the app freezes, but if we prioritize the JS event loop, then the HID callbacks are not called as quickly. I experimented with different values to find a better trade-off, but nothing seemed ideal. The current value seems fine for devices with low poll rates (<125Hz).

Related StackOverflow issue (no answer): https://stackoverflow.com/questions/33599653/c-callbacks-are-not-called-for-node-bindings
It seems that this problem could also be solved from the js code, by re-writing node's main loop to process macOS events, but it is pretty involved and require the use of platform dependent APIs in JS: TooTallNate/NodObjC#2

Tested on macOS Catalina.