Use of GATT security (peer_manager) when using the MESH_PROXY feature of a mesh/ble coexistence.

Question

Our original BLE stack application on the nrf52840 has integrated encryption. It uses LESC with MITM and bonding. 
 I have gotten a certain level of run time success with BLE and MESH coexistance on our platform. 
 nrf5_SDK_17.0.2 
 nrf5_SDK_for_Mesh_v5.0.0 
 I can successfully provosion the device and retrieve mesh model values from the provisioned device. 
 If I enabled MESH_FEATURE_GATT_PROXY_ENABLED in the mesh SDK, I can see GATT before and after provisioning (however after provisioning gets dicey, with the GATT coming in and out of being seen by nrf connect IOS) 
 We are working on adding mesh alongside our standard BLE GATT program. 
 My questions are: 
 If I want to access all the BLE GATT characteristics that I had setup originally in strict BLE with BLE/MESH coexistance, do I need the 
 MESH_FEATURE_GATT_PROXY_ENABLED as defined in nef_mesh_config_app.h 
 It certainly feels like it. If I successfully mesh provision the device and I don't have MESH_FEATURE_GATT_PROXY_ENABLED, the device seems to no longer advertise all the standard GATT characteristics we've setup. 
 If I want GATT after mesh provisioning, do I need MESH_FEATURE_GATT_PROXY_ENABLED? 
 Second question: 
 If I have turned bonding/pairing/encryption on multiple GATT characteristics in standard BLE, can I still use this encryption in mesh coexistence with mesh proxy enabled? Do I need it? 
 It appears that pairing/bonding might not be supported with mesh proxy as indicated by this area of source code in mesh_gatt.c 
 case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
 NRF_MESH_ERROR_CHECK(sd_ble_gap_sec_params_reply(p_ble_evt->evt.gap_evt.conn_handle,
 BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP,
 NULL,
 NULL)); 
 So far, I can access unencrypted characteristics before and after provisioning the mesh stack, but error out if access any of the characteristics with enhanced security are accessed at any time. 
 This is the previous definition of security on the characteristics in question: 
 ////This is the init state of peer_manger.
#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 1 /**< Man In The Middle protection required (applicable when display module is detected). */
#define SEC_PARAM_LESC 1 /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_DISPLAY_ONLY /**< Display I/O capabilities. */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size. */
 
 
////This is the init state of peer_manger.
// Security parameters to be used for all security procedures.
sec_param.bond = SEC_PARAM_BOND;
sec_param.mitm = SEC_PARAM_MITM;
sec_param.lesc = SEC_PARAM_LESC;
sec_param.keypress = SEC_PARAM_KEYPRESS;
sec_param.io_caps = SEC_PARAM_IO_CAPABILITIES;
sec_param.oob = SEC_PARAM_OOB;
sec_param.min_key_size = SEC_PARAM_MIN_KEY_SIZE;
sec_param.max_key_size = SEC_PARAM_MAX_KEY_SIZE;
sec_param.kdist_own.enc = 1;
sec_param.kdist_own.id = 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id = 1;


//The characteristics attribute read and write permissions are set with
BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM() 
 
 I referenced the example of PB-GATT turn on in the example provided here: 
 https://devzone.nordicsemi.com/f/nordic-q-a/53837/including-nrf5-sdk-for-mesh-functionality-in-an-nrf5-sdk-example/235538#235538 
 We also need PB-GATT as we want to provision via phone.