bluetooth: host: investigate Telink legacy adv resume after disconnect

[damien0x0023]

Background

This is an issue that needs to be fixed in our Telink fork Zephyr.

On Telink TLSR SoCs (TL7218X), a BLE peripheral cannot be reconnected after
a disconnect when using legacy connectable advertising.

project-chip/connectedhomeip@229070a#r3805029716

Information collected

From Andrii @andriy-bilynskyy (earlier debugging on B91):

The connection state transitions are:

disconnected -> adv-connectable   (advertising)
adv-connectable -> connected      (after connection)
connected -> disconnect-complete  (after disconnection)
disconnect-complete -> disconnected

The final disconnected -> adv-connectable transition never happens, so no
further connection is possible.

After disconnect, bt_conn_unref() triggers bt_le_adv_resume() in
subsys/bluetooth/host/adv.c. The guard

if (!(atomic_test_bit(adv->flags, BT_ADV_PERSIST) &&
      !atomic_test_bit(adv->flags, BT_ADV_ENABLED))) {
    return;
}

evaluates to "true" on Telink, so resume is skipped and the device stays
disconnected. Commenting out the whole guard fixes reconnection, but is a
hack. The flags need to be understood correctly since this is the common
vendor file.

From Zhihan @strandingneko-vivi :

Suggested configuring the controller with
blc_ll_configLegacyAdvEnableStrategy(LEG_ADV_EN_STRATEGY_2) in the Telink
SDK during bt_init, instead of the default LEG_ADV_EN_STRATEGY_3.

Experiments on TL7218X (peripheral_ht sample)

1. LEG_ADV_EN_STRATEGY_2 + upstream bt_le_adv_resume() guard

   The connection stays in "connecting" and the host repeatedly logs:

   No pending conn for peer <addr> (random)
   Unable to look up conn with handle 64
   

   STRATEGY_2 keeps advertising running regardless of connection state
   (only blc_ll_setAdvEnable controls it), which conflicts with Zephyr
   host's legacy-connectable state machine, so the host cannot match the
   LE Connection Complete event to a pending conn. Incompatible.

2. LEG_ADV_EN_STRATEGY_3 + PERSIST-only resume guard (this branch)

   Connects once, but advertising is not resumed after disconnect. This
   reproduces Andrii's original observation. Skipping the unreliable
   !BT_ADV_ENABLED check does not help, so the root cause is not the resume
   guard itself but the host<->controller state sync after connect/disconnect
   under STRATEGY_3.

@strandingneko-vivi @Jackie-Kilby
Please help investigate how to modify our Telink controller to match the Zephyr common Host.