Comment 8 for bug 1941977

I attached snoop/logs where the PC initiated the connection, for comparison. There, the issue doesn't happen, the headset calmly allows the PC to establish all the profiles since the PC connected the ACL.

One can also see the difference in flow:

Aug 29 01:57:02 RhoPC bluetoothd[4053589]: src/device.c:connect_profiles() /org/bluez/hci0/dev_FC_58_FA_7F_E5_18 (all), client :1.160
Aug 29 01:57:02 RhoPC bluetoothd[4053589]: src/service.c:btd_service_ref() 0x556620ba9bb0: ref=2
Aug 29 01:57:02 RhoPC bluetoothd[4053589]: src/service.c:change_state() 0x556620ba9bb0: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: disconnected -> connecting (0)
Aug 29 01:57:05 RhoPC bluetoothd[4053589]: src/adapter.c:connected_callback() hci0 device FC:58:FA:7F:E5:18 connected eir_len 9
Aug 29 01:57:05 RhoPC bluetoothd[4053589]: src/profile.c:ext_connect() Headset Voice gateway connected to FC:58:FA:7F:E5:18
Aug 29 01:57:05 RhoPC bluetoothd[4053589]: src/service.c:change_state() 0x556620ba9bb0: device FC:58:FA:7F:E5:18 profile Headset Voice gateway state changed: connecting -> connected (0)

THe HFP service entered state CONNECTING pretty much as soon as I tapped "Connect" in Blueman, even before the ACL was established. Then 3s later, it entered CONNECTED once the HFP SLC was established, courtesy of ext_connect().

I did a basic search and couldn't find anything that would be hurt by removing that CONNECTING transition -- pretty much every spot that checks for state CONNECTING during transitions, expects it to mean "this service connection was locally initiated". So we just need to make sure it means just that, especially since I see no other indicator accessible to listeners.

Since a bunch of guesswork was done to get here, it would be neat if someone experienced with the stack can confirm how much of this is even correct, and if the proposed solution makes sense :-)