When the user sends a response, the network can still continue the
dialog, it is not a final response and we cannot transition to an idle
state when the command finishes. Instead we set it back to a special
state and treat subsequent network responses as unsolicited.
This adds the methods on the D-bus interface to allow the
client to handle USSD requests from the network, according to 22.090.
Unfortunately this document is not clear on every point and some
details can't be implemented. This includes reporting unsupported
request to the network, unsupported language, ME busy etc, because
there isn't an AT command for that.
If the network requests user action in the response to an MO USSD, we
cannot immediately return to USSD_STATE_USER_IDLE. Instead,
USSD_STATE_USER_ACTION is entered.
Note that it is left up to the driver to notify() when the USSD
transaction is closed by the network due to inactivity. Another way to
return to USSD_STATE_IDLE is for the user to cancel() the transaction.
The registration was done by using the storage in the modem. Refactored
to use the new atom watch APIs and storing the control entries in the
ussd atom itself
This is slightly hacky, part of ussd.c responsible for registering services
is duplicated and parse_ss_control_string is modified to accept a fourth
SI fragment in the input string.