Bluetooth: CAP: Wait for both write response (or notification) and state change

[Thalley]

Summary

In general the CAP implementation only waits for either of the 2.

For the CAP Initiator procedures proc_done_cnt is based exclusively on the state of the ASEs in update_proc_done_cnt, and may continue with the next step before we have receive the control point notification, where ideally the next step should only be executed once we have received both the state change notification (if any) and the control point notification.

For the CAP Commander broadcast procedures, it's the same issue/case, with the difference that we get a write response instead of a control point notification.

For the CAP Commander volume and rendering procedures, we may not get a state change in all cases, e.g. if setting volume to 100 when it is already 100 will only trigger a write response, so in those cases we cannot rely on the state change. However none of these procedures have multiple steps, so it's less of an issue, if an issue at all.

Describe the solution you'd like

Before continuing to the next step in the CAP procedures, we should wait for both the "response" of the write request, and the expected state change. If we don't wait for the "response" we may be rejected and/or may require more ATT buffers than expected. If we don't wait for the state change, then we may initialize the next step too early for the CAP Acceptor.

For CAP initiator procedures we need to keep track of the control point notification and the ASE state change notification, and update_proc_done_cnt should not update proc_done_cnt until both have been received for a given proc_param.

For the CAP commander broadcast procedures we need to track of the write response and the receive state change. Perhaps we need a update_proc_done_cnt here as well.

Alternatives

No response

Additional Context

No response