Data track integration

[1egoman]

Integrates the data track managers (both incoming and outgoing) into the existing sdk Room and RemoteParticipant interfaces. Once this is merged, data tracks is fully implemented!

NOTE: This pull request is based on top of the data-track-incoming-manager branch and the diff will be weird until that one is merged here.

Interface - Publishing

const localDataTrack = await room.publishDataTrack({name: "data track name"});
await localDataTrack.tryPush(new Uint8Array(/* ... */));

// Once you are done with the local data track, it can be unpublished:
await localDataTrack.unpublish();

Interface - Subscribing

// There are two ways to get a remote data track, either a room event:
room.on(RoomEvent.RemoteDataTrackPublished, async (remoteDataTrack) => {
  // ...
});

// Or a new field on `RemoteParticipant`:
const remoteDataTrack = remoteParticipant.dataTracks.get("track name"); // Get a data track which has been published
const remoteDataTrack = await remoteParticipant.dataTracks.waitUntilExists("track name"); // Get a data track which _will_ be published shortly

// Either way, once you have a remoteDataTrack, you can subscribe:
const stream = await remoteDataTrack.subscribe(/* optional abort signal */);
for await (const frame of stream) {
  console.log(`Received bytes from ${remoteDataTrack.info.name}:`, frame.payload);
}

Todo:

• Decide on how to show the example app chart vs hexdump - show both? Just one? commit introducing chart.
• Add changeset

[lukasIO]

nit: naming

alternative suggestions:

• await(key)
• getAsync(key)

My take is that await(key) might be the cleanest. The getAsync isn't really a common pattern in JS.

[1egoman]

I will admit, I am not a big fan of either of those naming suggestions. To me await on its own doesn't make it clear that there is "getting a key" involved, and I also am not a super big fan of the repetition of await map.await("key").

Just to throw a few more options out there to see if we can find one we both like, here's some more potential options from a LLM:

• resolve(key) — Borrows from Promise terminology; implies the value will materialize.
• getDeferred(key) — Concise, borrows from the well-understood deferred/promise pattern.
• getEventually(key) — A little whimsical but honest about what's happening.
• getWhenAvailable(key) — Very explicit and self-documenting, though a bit long.
• getWhen(key) — Reads as "get when available," compact shortening of the above.
• getOnce(key) — Reads as "get once it's ready."

Thoughts on any of those?