rtpmanager/rtsession: race conditions leading to critical warnings

Conditions

While testing the implementation for insertable streams in webrtcsink & webrtcsrc, I encountered multiple critical warnings, which turned out to result from two race conditions in rtpsession. Both race conditions produce:

GLib-CRITICAL: g_hash_table_foreach: assertion 'version == hash_table->version' failed

In its simplest form, the test consists in 2 pipelines and a Signalling server:

• pipelines_sink: audiotestsrc ! webrtcsink
• pipelines_src: webrtcsrc ! appsrc

1. Set pipelines_sink to Playing.
2. The Signalling server delivers the producer_id.
3. Initialize pipelines_src to establish a session with producer_id.
4. Set pipelines_src to Playing.
5. Wait for a buffer to be received by the appsrc.
6. Set pipelines_src to Null.
7. Set pipelines_sink to Null.

First race condition

First race condition happens in the following sequence:

• webrtcsink runs a task to periodically retrieve statistics from webrtcbin. This transitively ends up executing rtp_session_create_stats.
• pipelines_sink is set to Null.
• In Paused to Ready, gst_rtp_session_change_state() calls rtp_session_reset().
• The assertion failure occurs when rtp_session_reset is called while rtp_session_create_stats is executing.

This is because rtp_session_create_stats acquires the lock on session prior to calling g_hash_table_foreach, but rtp_session_reset doesn't acquire the lock before calling g_hash_table_remove_all.

Acquiring the lock in rtp_session_reset fixes the issue and was implemented in this branch. I can open an MR if this seems acceptable.

Second race condition

Second race condition happens right after the first payload is received:

• rtp_session_on_timeout acquires the lock on session and proceeds with its processing.
• rtp_session_process_rtcp is called (debug log : received RTCP packet) and attempts to acquire the lock on session, which is still held by rtp_session_on_timeout.
• as part of an hash table iterator, rtp_session_on_timeout transitively invokes source_caps which releases the lock on session so as to call session->callbacks.caps.
• Since rtp_session_process_rtcp was waiting for the lock to be released, it succeeds in acquiring it and proceeds with rtp_session_process_rr which transitively calls g_hash_table_insert via add_source.
• After source_caps re-acquires the lock and gives the control flow back to rtp_session_on_timeout, the hash table iterator is changed, resulting in the assertion failure.

I'm not quite sure how to fix this without risking deadlocks.