Comment 7 for bug 1941977

That one's clear enough from the earlier log snippet and source:

Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/profile.c:ext_connect() Headset Voice gateway connected to FC:58:FA:7F:E5:18
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:change_state() 0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: disconnected -> connecting (0)
Aug 29 00:54:47 RhoPC bluetoothd[4046739]: src/service.c:change_state() 0x562f6441d710: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: connecting -> connected (0)

This ext_connect() seems to be called whenever a profile connection is completed, whether successfully or not, whether locally or remotely initiated. Above, we see the state changes it orchestrated -- it first transitions the HFP "service" to CONNECTING and then to CONNECTED pretty quickly:

 if (conn->service && service_set_connecting(conn->service) < 0)
  goto drop;
...
 if (conn->service)
  btd_service_connecting_complete(conn->service,
      err ? -err->code : -EIO);

Each of these state changes gets propagated to a bunch of listeners -- one of which is policy.c.

=========================
I think that first transition (to CONNECTING) should not have happened, because it takes away the ability of any listeners to judge whether a connection was locally or remotely initiated, and act accordingly. The HFP service should've simply gone from DISCONNECTED to CONNECTED -- that first IF block should be removed entirely.
=========================

If a connection were indeed locally initiated, the service's state would've been set to CONNECTING way back, by btd_service_connect() probably since it looks to be the one that kicks off the connection. ext_connect() only has enough info to make that final jump to CONNECTED.