Bluetooth: GAP name and appearance

[alwa-nordic]

There are at least 4 change requests to do with the GAP name and appearance API.

• bluetooth: settings: Make BT name persistance an option #93700
  Dynamic should not imply persistent.
• Bluetooth: Host: BT_DEVICE_NAME should be mutually exclusive with BT_DEVICE_NAME_DYNAMIC #93769
  The static value CONFIG_BT_DEVICE_NAME is a confusion hazard when BT_DEVICE_APPEARANCE_DYNAMIC=y.
• bluetooth: GAP Device Name and Apperance write callbacks #93723
  There is a lack of observer API for GAP values.
• Thread safety: Bluetooth: Host: Introduce new GAP Device Name APIs #88896
  The current API is fundamentally thread-unsafe.

I think it's best to address all these problems together. RFCs welcome.

[rkel]

Note that there is PR #93946 already for #93723.

[alwa-nordic]

I think we should open up for the possibility of allowing a custom implementation of bt_gap_get_device_name, etc.

[Thalley]

I think that makes sense, given that the upper layers/application is now the only one responsible for setting the device name in the advertising data (and seemingly, some devices like Android only use the advertised name, and not the characteristic itself).

[alxelax]

If this is the complex device e.g. ble + ble mesh are you going to provide events which name to advertise when?
I'd like better clarification for "custom implementation" since mesh inherits device name approach from host.

[rkel]

@alxelax We had dropped the solution with the callback in the favor of opening the possibility of custom implementation of GAP service: #94235

[alxelax]

Ok, I see. My main concern was incompatibility with the approach that mesh uses to set device name. Seems changes are not related to this.

[alwa-nordic]

I'd like better clarification for "custom implementation" since mesh inherits device name approach from host.

I mean that the Host defines the interface, i.e. that there exists a set of functions, including bt_gap_get_device_name(), and their API contract, but does not necessarily provide the implementation of these functions.

Mesh Profiles can expect bt_gap_get_device_name() to exists and read the current GAP Device Name. Implementations of Profiles that use the GAP Device Name value should use this API to obtain it. It shall give the same value as reading the local GAP Service Device Name characteristic.

The interface will probably need to include a way to subscribe to updates to the GAP Device Name. So we may need some kind of callback or other signal.