Rethink (refactor) participant package

[daniel-abramov]

The current participant package is not particularly useful, since Participant only provides public fields and does not do any encapsulation. The only reason it was moved there is the Tracker implementation. Tracker was created to ensure that 3 entities: subscriptions, published tracks, and participants are in sync.

However, after tackling #120 and #117, the published track along with its subscribers is extracted into its own package.

This means that the only thing that Tracker synchronized are 2 fields: participants and published tracks. It's easy to see that published tracks actually belong to the participant structure (and it was implemented like this at the beginning), however, they were split so that we could do a fast look-up of the published tracks by their IDs, which was required to ensure:

• fast subscribe/unsubscribe: when someone sends us a subscribe/unsubscribe command, they specify the track IDs, but not participant IDs, which means that if we stored published tracks inside participants, then we would need to first go over all participants and then over each participant's tracks to find the published track.
• fast selection of subscriptions when packets arrive to the new conference (this was due to participants sending their packets directly to the conference, this changes with aforementioned issues)

So once it's done, it would be good to review the participant and refactor it, so that:

• Participant contains publishedTracks inside it (it simplifies the clean-ups and managing tracks in general).
• Participant has all its fields as private providing a simple interface to interact with it that would ensure that all invariants that the participant has, are intact.
• Get rid of a Tracker (optional), and instead just store an additional map that contains trackID : ownerID relation. That way we just need to maintain the synchronous state of these two which would allow us to find the required tracks faster (make sure that it does not bring any performance downsides).
• Then part of the logic would be moved back to the Conference. This may not necessarily be bad since currently, the responsibility of the Conference overlaps with the Tracker a bit.