BLE: Added call to delete the security database object upon SM reset.

[AGlass0fMilk]

Description (required)

This patch deletes the security database object upon calling SecurityManager::reset().

Resolves #11768 (for now...)

Summary of change (What the change is for and why)

Previously, there was no normal method to have the security manager close the security database file (if using a file-based security database, as the Mbed SM does if not using a volatile, RAM-based database).

In some cases, this prevented the file from ever being fully flushed to flash if using a block device or filesystem that buffers write operations. The result of this was that for some applications/targets there was no official way to get BLE bonding persistence to work.

This fix allows the file to be closed by the OS and flushed to disk upon calling SecurityManager::reset().

Users should note that if calling SecurityManager::reset() to flush the database file to flash, they will also have to reinitialize the SecurityManager (set up an event handler, configure settings, etc).

Documentation (Details of any document updates required)

See issue #11768 for details.

---

Pull request type (required)

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results (required)

I identified the problem and fix through the following method:

Tested on target: EP_AGORA but should be same for all nRF52840-based targets.

1.) Upon startup, application initializes SPIFBlockDevice and FATFileSystem (also used LittleFileSystem with same results)
2.) BLE was initialized and SecurityManager configured to write to a file -- /fs/sec.dat
3.) nRFConnect and an nRF52840_DK were used to connect and pair/bond with the target -- triggering the SecurityManager to store keys related to the connection
4.) Upon disconnection, a USBMSD object was created to present the FATFileSystem as a mass storage device to my laptop
5.) While the file existed in both cases, when I inspected the size and content of the file I found that with the code currently in master the file was never written to -- size of 0 bytes. With this fix, the file is correctly written to and is 568 or so bytes in size.

[] No Tests required for this change (E.g docs only update)
[X] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers (optional)

@paul-szczepanek-arm

---

Release Notes (required for feature/major PRs)

Summary of changes

Impact of changes

Migration actions required

[ciarmcom]

@AGlass0fMilk, thank you for your changes.
@paul-szczepanek-arm @ARMmbed/mbed-os-pan @ARMmbed/mbed-os-maintainers please review.

[AGlass0fMilk]

@paul-szczepanek-arm

This fix is pretty much a workaround for the situation described above. However, after reviewing the SecurityManager API a bit more in detail I think there are some ways that it could be improved and made more flexible. We should start a discussion on future improvements to the BLE SM API presented by Mbed.

I have started a forum post here: https://os.mbed.com/forum/bugs-suggestions/topic/36266/

[paul-szczepanek-arm]

thanks, this helps but I guess we also need an automatic solution

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts