BLE_GAP_OP_NULL macro

GAP - Generic Access Profile. Design overview: GAP procedures are initiated by the application via function calls. Such functions return when either of the following happens: (1) The procedure completes (success or failure). (2) The procedure cannot proceed until a BLE peer responds. For (1), the result of the procedure if fully indicated by the function return code. For (2), the procedure result is indicated by an application-configured callback. The callback is executed when the procedure completes. The GAP is always in one of two states: 1. Free 2. Preempted While GAP is in the free state, new procedures can be started at will. While GAP is in the preempted state, no new procedures are allowed. The host sets GAP to the preempted state when it needs to ensure no ongoing procedures, a condition required for some HCI commands to succeed. The host must take care to take GAP out of the preempted state as soon as possible. Notes on thread-safety: 1. The ble_hs mutex must always be unlocked when an application callback is executed. The purpose of this requirement is to allow callbacks to initiate additional host procedures, which may require locking of the mutex. 2. Functions called directly by the application never call callbacks. Generally, these functions lock the ble_hs mutex at the start, and only unlock it at return. 3. Functions which do call callbacks (receive handlers and timer expirations) generally only lock the mutex long enough to modify affected state and make copies of data needed for the callback. A copy of various pieces of data is called a "snapshot" (struct ble_gap_snapshot). The sole purpose of snapshots is to allow callbacks to be executed after unlocking the mutex.