Description of the issue: Customer has reported that during their testing the CC23XX device (when operating as a peripheral using un-directed scan-able connectable advertisements) only responds to the first scan request received within an advertisement. They have verified this behaviour by using a LitePoint tester and measuring the current over time. The CC2340R5 responds to the first scan request, but completely ignores the scan request on channels 38 and 39. If the advertiser receives a SCAN_REQ PDU that contains its device address from a scanner allowed by the advertising filter policy, it shall reply with a SCAN_RSP PDU on the same primary advertising channel index. After the SCAN_RSP PDU is sent, or if the advertising filter policy did not allow processing the SCAN_REQ PDU, the advertiser shall either move to the next used primary advertising channel index to send another ADV_IND PDU, or close the advertising event. This means that a scan request must be responded to (if the policy allows it) before moving onto the next adv packet.

Steps to reproduce: To reproduce this, flashed a CC2340R5 device with an unmodified basic ble example. In addition, flashed 3 CC2340R5 devices with host_test images. The host_test devices were then configured to continuously actively scan forever. This maximizes the chance that the basic_ble device will receive more than one scan request within a single advertisement.