lib: bluetooth: peer_manager: associate peer_id with connection handle after the re-pairing allowed check, in case duplicate bonding data was found

[anhmolt]

If duplicate bonding data is found in auth_status_success_process(), first check if repairing is allowed before associating the peer_id with the connection handle. If repairing is not allowed, then the peer_id should not be associated with the connection handle.

[github-actions]

You can find the documentation preview for this PR here.

[PizzaAllTheWay]

Good catch on delaying the peer association until re-pairing is approved. I added a comment about evt_send() potentially needing an update too, please check if my reasoning is correct.

[PizzaAllTheWay]

With this change, auth_status_success_process() delays im_new_peer_id() until the application approves re-pairing. However, send_config_req() sets the detected duplicate peer_id in the event and then calls evt_send(), which immediately overwrites it using im_peer_id_get_by_conn_handle().

At this point the BLE connection exists, but it has not yet been associated with the detected peer ID. Therefore, the im_peer_id_get_by_conn_handle() lookup returns PM_PEER_ID_INVALID, and the application receives that instead of the duplicate peer ID needed for its custom re-pairing decision.

We could for example separate peer-ID selection from the actual event dispatch? For example:

static void evt_dispatch(struct pm_evt *event)
{
	for (uint32_t i = 0; i < SMD_EVENT_HANDLERS_CNT; i++) {
		evt_handlers[i](event);
	}
}

static void evt_send(struct pm_evt *event)
{
	event->peer_id = im_peer_id_get_by_conn_handle(event->conn_handle);
	evt_dispatch(event);
}

static void evt_send_with_explicit_peer_id(struct pm_evt *event, uint16_t peer_id)
{
	event->peer_id = peer_id;
	evt_dispatch(event);
}

[anhmolt]

Thanks. I have fixed the ->peer_id overwrite in evt_send() by moving that logic to the specific event function. Now the evt_send() is the same as in id_manager.c and security_manager.c.