Use livekit's Rust SDK instead of their swift SDK

[maxbrunsfeld]

See livekit/rust-sdks#355

Todo:

• make call / live_kit_client crates use the livekit rust sdk
• create a fake version of livekit rust API for integration tests
• capture local audio
• play remote audio
• capture local video tracks
• play remote video tracks
• tests passing
• bugs
  • deafening does not work (Can't stop a remote audio track from playing with RtcAudioTrack::set_enabled(false) livekit/rust-sdks#359)
  • mute and speaking status are not replicated properly: (Not receiving TrackMuted or ActiveSpeakersChanged events livekit/rust-sdks#358)
  • linux - crash due to symbol conflict between WebRTC's BoringSSL and libcurl's openssl (libwebrtc-sys conflicting with openssl-sys livekit/rust-sdks#89)
  • linux - libwebrtc-sys adds undesired dependencies on libGL and libXext
  • windows - linker error, maybe related to the C++ stdlib (windows: libwebrtc-sys conflicts with other crates that use C/C++ livekit/rust-sdks#364)

    libwebrtc_sys-54978c6ad5066a35.rlib(video_frame.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in libtree_sitter_yaml-df6b0adf8f009e8f.rlib(2e40c9e35e9506f4-scanner.o)
    

  • audio problems

Release Notes:

• Switch from Swift to Rust LiveKit SDK 🦀

[SomeoneToIgnore]

Small heads-up for the participants interested: we're about to merge this PR and test it internally.
This is NOT ready for Linux yet, but seems to fully replace the old macOS Swift SDK without any issues found so far.

Next rough steps look like this:

• supporting Linux audio
• fixing audio issues with wireless earphones and other dynamic frequency devices (same issue is in the old SDK, but now we can control things and fix it, finally)
• work on Linux screenshare and fixing whatever odd segfaults certain Linux distros experience