GapBondMgr doesn't Queue Pairing if Pairing is Ongoing

Git/Installer Release Version: SDK_CC13XX_CC26XX 4_10_00_78

Product Version: BLE5 Platform: CC26X2R1

Application: Anything that uses gapbondmgr

Problem description:

The gapbondmgr does not support simultaneous pairings. However, it does have support for queued pairings whereby if a pairing is ongoing when a new connection is established, the pairing will be queued to start after the ongoing pairing is finished. I believe this works if the gapbondmgr is initiating the pairing (i.e. the GAPBOND_PAIRING_MODE parameter to GAPBOND_PAIRING_MODE_INITIATE).

However, if instead of the second pairing being initiated from the gapbondmgr, it is initiated from the application via the GAPBondMgr_Pair(), this API will return with bleAlreadyInRequestedMode:

// Ensure that we're not already pairing  
if (GAP_isPairing())  
{    
    return bleAlreadyInRequestedMode; 
}

I would expect it to queue the pairing for later completion, the same as happens in the normal case. As a side note, it does probably make sense to ensure that pairing with the same peer is not ongoing. However, GAP_isPairing() just checks that any pairing is ongoing.

To replicate:

1. On the DUT (based on default simple_central), set GAPBOND_PAIRING_MODE parameter to 
   GAPBOND_PAIRING_MODE_WAIT_FOR_REQ. This will prevent the gapbondmgr from automatically starting pairing. Also ensure that the peer device (perhaps simple_peripheral) does not initiate pairing.
2. Connect to peer 1 and initiate pairing from the DUT with GAPBondMgr_Pair(). This can be accomplished by calling this API from the application once the application has received the GAP_LINK_ESTABLISHED event.
3. Connect to peer 2 and, before pairing has finished with peer 2, initiate pairing to pair 2 by calling GAPBondMgr_Pair(). This will happen automatically based on the previously discussed code change. Note that you must ensure that this happens before peer 1 pairing has finished. So perhaps use long connection intervals and a type of pairing that takes a while (such as secure connections passcode). If you really wanted to, you could add GPIO toggling or print statements to compare the timing.
4. See that GAPBondMgr_Pair() returns with bleAlreadyInRequestedMode instead of queueing the pairing.