Element Call now sends a 'close' widget action when the widget is ready to close. Usually this will be sent immediately after the 'hangup' action, but it could be sent later if the widget wants to present an error screen before closing. So by listening to the 'close' action rather than the 'hangup' action, we get to see these error screens.
* Introduce a `MediaEventsTimelineFlowCoordinator`
* Update SDK API and architecture
* Add a feature flag, add translations
* Move the media events timeline presentation under the room flow coordinator state machine
* Rename `TimelineViewState.timelineViewState` of type `TimelineState` to `timelineState`
* Enabled SwiftLint's `trailing_closure` rule and fix the warnings.
* Fix a race condition observing room info updates for calls.
* Fix a bug where call observation wasn't set up if the call comes when the app has been killed.
* Fixes#1227 - Add support for receiving and interacting with incoming session verification requests.
* Fix a couple of random small warnings
* Move static view config to the view state
* Update snapshots
- previously handled in 7818fa626ae0c8ccacca1ccaeffe6998359dd38d
- seems the default behavior changed and we now need to manually configure the AudioSession
* Use native video call picture in picture!
* Handle isSupported, isPossible and web view errors.
* Use new canEnterPip method.
* Hide a room's Call button when already joined to the call.
* Tweak feature flag description.
* PR comments.
* Remove incorrect message send call and fix typo.
* Add overlay coordinator presentation to the NavigationRootCoordinator.
* Remove GenericCallLinkCoordinator, merging it into CallScreen.
This will allow for picture in picture on call links when available.
- we're currently working around the widget not properly aquiring media streams by manually terminating a call before starting the web view
- it seems that there's a race condition between that and the system opening the app
- as such we need to delay terminating the call until the system gets a chance to handle the redirect
- CallKit decides what action to to take when pressing the hardware lock button based on where the audio is routed to. Using the speaker will make it lock the phone while using the headset will make it end the call.
- Before the introduction of CallKit we had to manually setup the AudioSession to keep the audio live in the background. This is now clashing with CallKit making it bevelie the audio is not routed to the speaker and causing the call be terminated when pressing the lock button.
- not completely sure why this happens but `reportOutgoingCall` interferes with how the WebView gets access to video streams
- the call itself isn't really necessary so removing it is the simplest way forward
- tear down ElementCall screens when ending the call from the CXCallController
- make the call UI available in the task manager and lock screen
- Fix broken hang up widget message format
