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]

question: Should this be calling self._close() or self.close()? I think potentially the latter is needed here because otherwise the self._ffi_handle is never cleaned up.

[ladvoc]

Good question! This is the pattern used in other parts of the codebase, and I think this is safe since FfiHandle has its own __del__ that calls dispose().

[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?