Expose DataChannel buffer status events

[lukasIO]

(will revert the changes to example.ts, but helps with testing)

[changeset-bot]

🦋 Changeset detected

Latest commit: ca77ee6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
livekit-client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[davidzhao]

The implementation looks good!

Wanted to think through the API a bit more though. Is there any way for this to be easier to use? The current design is event -> push. which follows the data channel usage pretty closely. However, this seems kind of tricky to write programs for. Primarily because we'd leave the user to coordinate event handler code with their data source. (it's also difficult to know how much data to write at the same time)

[lukasIO]

Options to make the API easier would most likely just move the buffer to a different place in the code.
E.g. if the client sdk was responsible of sending data when the channel is ready to send more data, we would have to buffer incoming messages within the sdk instead. Not sure if that's preferable.

There are two different scenarios I can think of:

1. Send a large amount of data as quickly as possible
2. Send updates (e.g. positional data) as often as possible, it's important for the latest state to be sent, but less important that every state change gets sent out (e.g. I'd rather send the current position instead of sending outdated positions a couple of times while waiting for the buffer to clear)

[davidzhao]

Options to make the API easier would most likely just move the buffer to a different place in the code. E.g. if the client sdk was responsible of sending data when the channel is ready to send more data, we would have to buffer incoming messages within the sdk instead. Not sure if that's preferable.

There are two different scenarios I can think of:

1. Send a large amount of data as quickly as possible
2. Send updates (e.g. positional data) as often as possible, it's important for the latest state to be sent, but less important that every state change gets sent out (e.g. I'd rather send the current position instead of sending outdated positions a couple of times while waiting for the buffer to clear)

Yeah that's fair. for 2. the current API should still work ok I guess. Agreed we shouldn't cause everything to be buffered and keeping the native data channel notifications is the low-friction path.