Wrap thrown errors into Promise.reject for consistency.
Handle case when JitsiLocalTrack#dispose() is called after track was removed from conference.
Set track's conference reference to null when removing track from conference.
If the API client happened to try to add one and the same local video
track twice, the library would throw an error. I find that draconian
because:
1. The error message states that a second local video stream cannot be
added but that is incorrect because the API client is not trying to add
a second local video stream but add one and the same local video stream
multiple times.
2. The jsdoc says that a throw will happen if another local video stream
is added but that is misleading because the API client is not trying to
add another local video stream but add the same local video stream.
3. Adding one and the same local video stream multiple times can be
handled gracefully by the lib-jitsi-meet library. Thus, the library
appears more friendly.
Hence, gracefully handle the case of adding the same local video track
multiple times without throwing an error.
Since (1) half of the disco uses check whether the feature in question
is supported, (2) the other half appears to not absolutely require
disco, and (3) disco needs to be explicitly included/required in order
to be supported, make disco completely optional.
While we have JitsiMeetJS defined as a global variable in Jitsi Meet, it
doesn't sound like an absolutely necessary and beautiful requirement
inside the library itself.
Rename "stream" to "track" in RTC context plus fixes
Rename variables with "stream" in name which refer to JitsiTrack.
Rename TRACK ADDED/REMOVED events.
Try to reduce direct access to remoteTracks object.
Log warning message when track is overwritten.