Data tracks support

[ladvoc]

No description provided.

[pblazej]

Some things from talking to claude (maybe you find it useful):

• SubscribeDataTrackError / PublishDataTrackError not exported
• existing streams use aclose() (async), while DataTrackSubscription uses close() (sync); all of them can probably leverage https://www.geeksforgeeks.org/python/aenter-in-python/
• no remote_data_track_unpublished event - just mirroring rust comment here
• try_push should probably be push in python
• remote_data_track_published should be data_track_published as other tracks
• DataTrackFrame(payload=...) may validate the input type (what happens if you pass a string etc.)

[1egoman]

question: Should the python implementation of data tracks be updated to have the synchronous track.subscribe() behavior which was implemented in javascript, with any subscription errors cascading down into the first iterator __anext__ call?

[1egoman]

Discussed on slack with @ladvoc, we decided this behavior makes sense to do here as well!

[1egoman]

question: Is it worth exposing a more rich set of errors here instead of just the single error with the message, like rust / js have added?

[ladvoc]

I debated this and went with a string for now for three reasons: first, we may need to add new cases while this is still under development; second, using strings matches the existing FFI pattern, even though Rust supports error enums; and third, given how this FFI interface works there would be fair amount of boilerplate, including Protobuf definitions and public enums in each client language so we do not expose Protobuf types. What do you think?

[1egoman]

thought: I realize this could get out of date quickly if the default starts changing a bunch, but it might be nice to actually include the default value here (I think it is 16?).

Or maybe another alternative to sidestep that duplication concern could be to link to the future docs page (probably will be https://docs.livekit.io/transport/data/data-tracks/#buffer-size) where this is mentioned.