- In bap_unicast_client, it was assumed that ASE is binded with CIS
handler during sending "received_stop_ready" to unicast_server.
- In case where unicast_client has not started the stream with
"receiver_start_ready" att command to server, but wants to disable
ASE which was Enabled previously (but not stream!) causes failure
since there is no cis_create has happened and linked to ASE.
- In BAP_TS, "BAP/UCL/SCC/BV-103-C" has a same test conditions where
client first enables the ASE, disable the ASE, and expecting
"receiver_stop_ready" att command from client to server followed by
server notification to enter its ASE in QoS_configured state.
- Removed this condition checks to send expected att command to
server from Enabling ASE state to Disable ASE.
Signed-off-by: Nirav Agrawal <nirav.agrawal@nxp.com>
b59d8d56bf