Recreate CXProvider if a call cannot be hung up

[Anderas]

Resolves element-hq/element-ios#5189

Ways to reproduce

As mentioned in the ticket, this issue can be reproduced more directly by:

1. Recieve a call anywhere in the app
2. Accept the call from the in-app overlay header (no need to interact with the timeline)
3. Hang up the call

=> The app hungup the call, but the system still shows it as ongoing.

I must have repeated this over 200x, experiencing this issue about 10% of the times, without doing anything obviously different.

Root cause

It does not help that the Matrix SDK ignores all errors when requesting CallKit transactions. In fact once they are logged, two errors in particular happen at different times when hanging up the call: CXErrorCodeRequestTransactionErrorUnknownCallProvider and CXErrorCodeRequestTransactionErrorUnknownCallUUID. Every time I was able to reproduce the issue with "stuck" call, one of these errors was reported.

Through extensive logging I was able to rule out that we have some kind of UUID issue and so this must be some internal problem of CallKit that we do not see into. Similarly "unknown provider" suggests that our CXProvider was not correctly setup, but this is also not the case.

What I can conclude from this is that some kind of race condition happens between the different requestTransaction calls, which complete asynchronously, and this leaves the call in an inconsistent state (e.g. trying to end the call before the CXAnswerCallAction has completed, even though the call is ongoing).

Solution

The subtitle is a misnomer because I did not find an actual solution to the assumed race condition. I have however added logs for all the errors, and in the case of error in CXEndCallAction which causes the hangup we now call a resetProvider manually, which if nothing else, will actually shut down the hanging call (verified experimentally). Whilst this does not address the root cause, it resolves the symptop and makes sure the call is ended.

[gileluard]

LGTM 👍