Prevent race in participant update.

[boks1971]

In load test, participant updates were racing causing subscription failures. The sequence is

• Join response received
• Read worker started
• Add remote participants from join response
• But, before that could happen, because the read worker is active, there was a participant update which contained track information. That path added the remote participant before join response handler could add it.
• Eventually join response path comes around and adds the remote participant, but that version of remote participant info does not have the tracks yet. And it ends up overwriting the participant info. And it also drops tracks that are not there in the update.
• As the order got reversed, tracks added by participant update path gets wiped out by join response path.
• And subscription fails.

Adding a simple fix to reject participant info updates that are older version.

It will probably be better to process join response fully? Maybe, start the read worker only after processing join response?

NOTE: When the remote participant gets created via the participant update path, the local participant itself is not set up fully.

[boks1971]

It will probably be better to process join response fully? Maybe, start the read worker only after processing join response?

Irrespective of the above, I think the change in this PR is good as there is another path also where a remote participant is added before ParticipantInfo. That is in handleMediaTrack path. In this case, there are two ParticipantInfos trampling on each other. In the media track case, a minimal ParticipantInfo is synthesised. That will have version 0. So, the version check here should still work.