Keep the BLE workflow connection alive across VM restarts

[dhalbert]

• Fixes BLE Workflow using Chrome pairs but doesn't respond #10785

Claude wrote the code and found the underlying bugs; I directed, reviewed, and tested, and rewrote this post and some code comments.

(Part of the series of small PRs replacing #11178, following #11225, #11236, and #11237.)

Problem

Typing at the "Press any key to enter the REPL" prompt over BLE workflow serial closed the connection after exactly one character: the first byte breaks main.c's wait loop, which calls bleio_reset(). That disables and re-enables the full BLE stack, which drops every connection, including the workflow's. Ctrl-D reloads dropped it the same way.

Reset Fixes

• bleio_reset() now restarts the BLE stack only when user code created a GATT service. That is tracked by a flag set in the shared-bindings Service constructor. BLE workflow services are created through common-hal directly and do not set the flag.
  The only reason to restart the BLE stack is to clear user services from the GATT table. There is no way on nordic to clear those services; there is such an API on espressif, but we don't use it yet (could be a future PR).
• bleio_user_reset() now tears down user BLE state individually on every VM reset: it stops user scanning and advertising (as before), and now also disconnects the connections that user code initiated or accepted with its own advertising. A user_owned flag was added to the Connection object. The BLE workflow connection is not user-owned and stays up. This implements espressif's old "TODO: Don't stop BLE workflow connection."
  Since the restart no longer always runs, bleio_user_reset() also clears the adapter's and connections' pointers into the VM heap, which the restart used to clear implicitly.

Related cleanup

• Cleaned up ble_hci reset by deleting reset_devices() in main.c and moving some code from bleio_reset() to common_hal_bleio_init(). This avoided a double reset (which was harmless). These changes don't affect the other ports. (Noticed by @dhalbert)
• Improved comments in various places.
• Removed dead vm_used_ble and cccd_uuid declarations from silabs, copied long ago from ble_hci and never used.

Service Changed Problem

(This was an additional problem discovered while debugging. It's related to resets so @dhalbert included it in this PR.)

If you run _bleio code that creates services while the BLE workflow is running, the set of services presented by your board changes. A bonded host caches the GATT table across reconnects, and assumes the services are the same. To tell the host that the services change, the device should send a Service Changed indication.
Service Changed was done wrong on nordic and not done at all on espressif, so a reload that added or removed services left hosts writing to stale handles. That is unreportable at the ATT layer and caused the REPL serial connection to look dead.

Service Changed Fixes

• Nordic sent the indication only when the bonded system-attribute load succeeded. It also didn't use precise arguments for the service attribute range that changed: it used 0xC-0xFFFF for the range. The call to sd_ble_gatts_service_changed() failed, but we ignored the error. Now the populated range is tracked as attributes are added, and Service Changed is sent with that range on every bonded reconnect.
• Espressif never sent Service Changed at all. Now ble_svc_gatt_changed() is called after the cycle rebuilds the table; NimBLE indicates connected peers immediately and records the change for bonded peers, indicating them when they reconnect.

Both verified with btmon: a correct Service Changed goes out, and the host confirms, rediscovers, and resubscribes.

Not being afraid of disconnects

In the #11178 review, @tannewt suggested accepting connection drops on reload, since BLE is designed for flaky connections and bonding makes reconnection cheap. This PR takes a middle position: it keeps the disconnects that mean something and removes the ones that don't.

• If a reload changed the board's services, the connection still drops, because the stack restart requires it. That disconnect now works properly end to end: bonds survive, the host reconnects, and the Service Changed indication tells it to rediscover.
• If a reload changed nothing, the connection now stays up. Dropping it would tell the host nothing, and would cost a full reconnect: connection setup, re-encryption, rediscovery, and resubscription. That's several seconds of dead air on every save-and-reload during development, which is exactly when the serial connection is being watched.

Testing

Tested on a Feather nRF52840 Express and a Metro ESP32-S3 with the web editor on Linux, verified with btmon. Some testing on Windows and macOS also done. macOS is by far the most robust.

• If there is no user code that creates services, a disconnect does not need to happen, and doesn't.
• A test code.py created services that would need to be cleaned up when it stopped. In that case a clean disconnect is done on reload (not a supervision timeout). Reconnecting works: the host receives Service Changed, rediscovers, and file transfer works.
• A heap-churn soak (scan, connections tuple, allocation churn, 10+ reloads) showed no corruption or safe-mode resets.

Note: a known, pre-existing espressif PacketBuffer send bug, to be fixed in a following PR, can hang reloads while the web editor is connected. It also affects long file-directory listings on current main.

There are still problems with web-editor: it is slow to notice board-initiated disconnects, and after its automatic reconnect the serial pane does not re-acquire its characteristic, so typing goes nowhere. I'll file fixes for that later. But the fixes here will allow those fixes to succeed.

[tannewt]

Two minor things. Thanks for the fixes.

[tannewt]

Thank you!

[dhalbert]

I'm going to merge this anyway because the zephyr test timeouts I think are fixed by changes in #11226.