RFC: Restructuring the samples/bluetooth folder

[carlescufi]

Hi everybody,

The samples/bluetooth folder has been growing organically for a few years now, and the number of samples has become unwieldy. It is time to reorganize it so that it is easier to browse and maintain.

We are starting this discussion to provide users with the means to give feedback as to what the preferred options would be. The maintainers of the Bluetooth subsystem have put together an initial proposal, that you can find below. Please comment on this discussion with your opinion and feedback.

Proposal for restructuring. List of top-level folders in samples/bluetooth:

broadcaster/{beacon, eddystone, bthome_sensor_template, direct_adv, periodic_adv*, ...}
observer/{observer, scan_adv, periodic_sync}
central/{central*}
peripheral/{peripheral*, st_ble_sensor }
iso/
audio/
hci/{hci_*}
direction_finding/{}
mesh/
misc/{handsfree, ipsp, mtu_update (maybe split up into 2 samples)}

CC @jhedberg @Thalley @alwa-nordic @kruithofa @microbuilder @theob-pro @cvinayak @jori-nordic @wopu-ot @aescolar @thomas-ot @JordanYates @erwango @kartben

[JordanYates]

Generally makes sense, there is a question around where the multi-role samples should go (scan_adv)

[kartben]

This will be a nice improvement! Some comments:

• It will be necessary to setup redirects so that people browsing samples on say LTS version of the documentation do not land on a 404 when clicking "The latest development version of this page may be more current than this released xyz version."
• It would be worthwhile looking at whether some very old samples may not be relevant anymore? The answer might very well be "no" but I think it's worth looking at opportunities for extra housekeeping
• I would recommend looking at creating some documentation snippets/fragments, either at the top-level samples/bluetooth level or for each sub category so that each sample's README duplicates less information (ex. often the "Requirements" or "Building and Running" instructions would be virtually identical for many samples). The .. include:: directive can then be used to include said fragments in the relevant sections of the samples' READMEs.
• Bonus points if the BT samples also adopt zephyr:code-sample Sphinx extension :)