bluetooth: bluetooth host: Adding the same device to resolving list

[ibaz-nordic]

Describe the bug
Core v5.3, Vol 4, Part E, 7.8.38 specifies:
If an entry already exists in the resolving list with the same four parameter
values, the Controller shall either reject the command or not add the device to
the resolving list again and return success. If the command is rejected then the
error code Invalid HCI Command Parameters (0x12) should be used.

Core 5.2 however doesn't mention the option.

This means the Bluetooth host should be able to handle both outcomes from the controller.

If a remote device has been added to RL before, then the local device changes its advertising address, and the remote device tries to pair with the new address, we could end up trying to add the same data to RL.

Expected behavior
The host should not issue HCI_LE_Add_Device_To_Resolving_List for devices already on the list. Or it should ignore the error in that case.

Impact
Low/negligible. Only the log indicates an error. Everything seems to work fine from user perspective.

Logs and console output
[00530287] bt_hci_core: opcode 0x2027 status 0x12
[00530288] bt_id: Failed to add IRK to controller -5

[Thalley]

Re-opening since the PR that closed this was reverted: #46505

[alwa-nordic]

I believe this issue is describing a symptom that may be indicative of more serious problems. The host should never be in a state where it has two bonds with the same address or IRK. The current implementation keeps the bonds and the resolve list in sync. Either all or none of the bonds are on the resolve list. It follows then that it should be impossible for the host to attempt adding the same device to the resolve list twice. I believe the true error is that the host's bond manager does not refuse updating a bond with an address or IRK that is already used for another bond. Whatever process is trying to add this bond should either abort or unpair the conflicting bond before it can continue. The unpairing will propagate to the RL and fix this symptom.

[carlescufi]

Closing this as it is not a real issue.