Bluetooth: CAP: Reception stop may hang for already-stopped receive states

[Thalley]

Describe the bug

The bt_cap_commander_broadcast_reception_stop function will attempt to do a bt_bap_broadcast_assistant_mod_src first to stop the PA and BIG syncs, before removing the receive state with bt_bap_broadcast_assistant_rem_src when it receives a receive state update via notification. However in the case that the receive states are already stopped, then the write request may be accepted, but where we will likely not get a receive state notification since there is no state change. In this case, the procedure will never complete (until cancelled by the user).

Regression

• This is a regression.

Steps to reproduce

Use e.g. the BT shell to trigger bt_cap_commander_broadcast_reception_stop via the cap_commander broadcast_reception_stop shell command on a device with an inactive receive state, and notice the lack of the callback.

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

Sha: 458e6f8

Additional Context

Possible solutions are to read the receive state first to verify the state before doing any writes, or to cache the PA and BIG Sync states in struct bap_broadcast_assistant_recv_state_info in the BAP broadcast assistant so that the API of that can reject it immediately. If the receive state is already stopped, the CAP broadcast reception stop procedure could just do the remove source.