Race condition: Futures can wait on an async_id that's already been delivered to `PushEvent`

[artgillespie]

Thanks for all the recent updates @xianshijing-lk!

In my application, I'm calling room.localParticipant()->publishData(...) at 10Hz with a tiny (34 byte) payload in a loop from the main thread of a ROS node.

The amount of time varies, but eventually the call will block indefinitely.

I traced this down to this call fut.get(): https://github.com/livekit/client-sdk-cpp/blob/main/src/local_participant.cpp#L68

Further debugging identified the root cause: the FfiEvent with the corresponding async_id is delivered in the short window between calling sendRequest and registering the async handler.

I've patched LocalParticipant::publishData locally so that the fut.get() is instead a fut.wait_for(...) to get unblocked (let me know if you'd like a PR!), but it might be worth having a discussion about how we might update the core ffi async handling to avoid this issue.

[xianshijing-lk]

Thanks, the race conditions happen as the C++ needs to send a request to FFI layer, then setup the listener based on the async_id it get from the request response.

I think we can completely solve the problem if we do this:
C++ generate a request_id, then setup a listener to listener;
C++ send the request with the request_id to ffi layer
C++ listener will look at the request_id to get the right response.

I believe this will solve all the relevant racing conditions that theoretically happen on all platforms

[xianshijing-lk]

This should be fixed by #43, which will setup the listener before sending the ffi requests.