Indicators should not be updated if:
- multiple separate calls are active at same time
- a conf call and a call are active at same time
- multiple separate calls are held at same time
- a conf call and a call are held at same time
- a conf call has call in active and held state
HFP does not implement HangupAll natively and most AGs do not support
releasing held calls by id. Work around this by using hangup active and
then dropping all held calls if no waiting calls exist. Otherwise
fall back to releasing calls by id.
If we have a single held call, then it should be possible to hang it up
with 'Hangup' even if active calls exist. Only if multiple held calls
or a waiting call exists should we disallow the request due to possible
side-effects.
Fix PTS test TP/TWC/BV-03-I [Call Waiting- Hold Active/Retrieve
Waiting Call or Held].
PTS test fails after receiving intermediate update of callheld indicator
with value 0 (no held call) before it receives update to value 1
(active and held calls). This is due to the non-atomic update of calls
status after call swap (moving first call to active state before moving
second one to hold state).
HFP 1.5 spec specifies that an update of callheld indicator to 1 should
be sent after AT+CHLD=2 command.
As oFono emulator sends +CIEV only if the indicator value changes, we
need to use an intermediate state for callheld indicator (2, all calls on
hold).
So, in case of multiple active calls, or an active call with an active
mutiparty call, force update of callheld indicator to 2.
It is not safe to call dial_request_user_cancel directly. This is
because there might be a situation where the SIM requested the calls to
be dropped first. If we're still executing the release_all_active
request and someone calls hangup -> crash.
Instead it is safer to throttle the hangup requests until the call is
actually dialing.
In similar fashion, we should not allow hanging up a specific call if a
dial request is active, unless that call is part of the SIM dial
request. Note that by default this is not known until the driver's dial
implementation returns and the call is in the dialing (or alerting /
connected) state.
Make sure that only a single request from (possibly multiple) emulators
is ever sent to the voicecall driver. In the beginning it wasn't clear
whether this will be necessary, however several command implementations
already implemented basic throttling (+CHUP, ATD, CHLD=3, CHLD=2x) and
it made sense to make this more formal.
The other constraint is the abrupt removal of the emulator atom while an
operation is pending. This case must be handled gracefully. See next
commit.