Bluetooth: hci_sync: annotate data-races around hdev->req_status

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sync: annotate data-races around hdev->req_status

__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:

hdev->req_status = HCI_REQ_PEND;

However, several other functions read or write hdev->req_status without

holding any lock:

- hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)

- hci_cmd_sync_complete() reads/writes from HCI event completion

- hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write

- hci_abort_conn() reads in connection abort path

Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while

hci_send_cmd_sync() runs on hdev->workqueue, these are different

workqueues that can execute concurrently on different CPUs. The plain

C accesses constitute a data race.

Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses

to hdev->req_status to prevent potential compiler optimizations that

could affect correctness (e.g., load fusing in the wait_event

condition or store reordering).