Bluetooth: GATT: CCC and CF values written by privacy-disabled peer before bonding may be lost

[MarekPieta]

Describe the bug
Values of CCC and CF may not be stored in non-volatile memory if a connected peer writes the values before it's bonded. If the peer then bonds and reboots without disconnection, the values written over GATT will be lost (they would not be stored in non-volatile memory). On the other hand if the same peer disconnects after bonding an before the reboot, these values are written to non-volatile memory.

To Reproduce

Used nRF Desktop application (applications/nrf_desktop) from nRF Connect SDK (https://github.com/nrfconnect/sdk-nrf).

Steps to reproduce the behavior:

1. Flash the nRF52840 DK with configuration that works as HID keyboard
   west build -b nrf52840dk_nrf52840 --pristine -- -DCONF_FILE=prj_keyboard.conf
west flash --erase
2. Add logs when the following functions are called in bluetooth/host/gatt.c: cf_write (CF value GATT write), cf_set (CF value loaded from non-volatile memory).
3. Connect and bond with a Bluetooth Central.
   Make sure that the connected Central uses GATT Caching and triggers the CF GATT write only before bonding (otherwise the issue would not replicate; I replicated the problem with a Windows 10 Bluetooth host).
4. Reboot Zephyr device while the Bluetooth connection is still maintained.
5. Notice that CF value written for the bonded peer is lost (it's not loaded from settings).

If the peer is disconnected before the reboot, the value is stored during the disconnection (that works around the issue).

Expected behavior
CF and CCC values should be stored between connections for bonded peers.

Impact
Implementation of Zephyr's Bluetooth host is not consistent with the Bluetooth Core specification.

The Bluetooth Core specification (v. 5.2, vol. 3, part G, section 3.3.3.3):
The Client Characteristic Configuration descriptor value shall be persistent across connections for bonded devices.

The Bluetooth Core specification (v. 5.2, vol. 3, part G, section 7.2):

A Client Supported Features characteristic value shall exist for each connected client. For clients with a trusted relationship, the characteristic value shall be persistent across connections. For clients without a trusted relationship the characteristic value shall be set to the default value at each connection.

Environment:
Replicated on nRF Connnect SDK (https://github.com/nrfconnect/sdk-nrf; commit hash: 5be84b48937b0c42fb2b8d643ef452a25a693f17).

Additional context
Similar issue was already spotted some time ago:
#39989

Seems that the introduced fix does not cover all of the edge cases:
#40006
The fix relied on storing the CF and CCC on identity_resolved callback which may actually not be triggered e.g. if the connected peer does not support privacy.

I would suggest to trigger an additional write to storage of the mentioned values also on pairing_complete from bt_conn_auth_info_cb to prevent the issue.