Stop BLE log streaming from starving the NimBLE notify pool

sendLog() notified once per firmware log line with no backpressure. With
debug_log_api_enabled and a subscribed client, a logging burst drains the
msys_1 mbuf pool that every GATT notification and ATT response allocates
from, so ble_gatts_notify_custom starts returning BLE_HS_ENOMEM (rc=6) --
for the fromNum doorbell too, not just the log line that exhausted it.
Each failure then prints an error over serial at ~12ms apiece, which is
itself enough to throttle the main loop during a burst.

Register a callback on the log characteristic so the host's own
ERROR_GATT verdict pauses log notifies for 250ms and lets the pool
refill. Keying off the failure rather than a free-block count keeps this
correct however the pools are sized.

Also restore CONFIG_BT_NIMBLE_MSYS_1_BLOCK_COUNT to the IDF default of
12. Pool selection is by block size and a notify request always resolves
to the smallest pool, so msys_1 is the only pool GATT draws from; 8 was
thin once anything chains or fragments. msys_2 and the ACL/EVT transport
pools are left trimmed -- neither is on the notify path, and restoring
the full defaults would re-spend the contiguous allocation that #10741
was fixing on heap-tight boards.

sendLog() also lacked the null check onNowHasData() already has, so a log
line arriving during BLE teardown dereferenced a freed characteristic.

Fixes #11245

Author: thebentern

src/nimble/NimbleBluetooth.cpp

@@ -637,6 +637,30 @@ class NimbleBluetoothFromRadioCallback : public BLECharacteristicCallbacks
     }
 };
 
+// Debug-log streaming is best-effort, but it competes for the same resources as the traffic that
+// isn't. Every GATT notification allocates from the NimBLE host's msys_1 mbuf pool, and log_to_ble()
+// attempts one notification per log line, so a logging burst (a config import, the position replay
+// that runs at every connect) drains the pool faster than the link gives it back. Once it is empty
+// the fromNum doorbell and ATT responses fail too, and each failed notify costs an error print on
+// the serial console -- which produces more log lines, at ~12ms apiece.
+//
+// So treat a rejected log notify as backpressure: stop offering log lines to the pool for a moment
+// and let it refill. This keys off the host's own verdict rather than a free-block count, so it
+// stays correct no matter how the pools are sized.
+static constexpr uint32_t kLogNotifyBackoffMs = 250;
+static std::atomic<uint32_t> lastLogNotifyFailureMs{0};
+
+class NimbleBluetoothLogRadioCallback : public BLECharacteristicCallbacks
+{
+    void onStatus(BLECharacteristic *, Status s, uint32_t) override
+    {
+        // Only ERROR_GATT means the host refused the notification (BLE_HS_ENOMEM when the pool is
+        // dry). The no-client/no-subscriber statuses are normal and return before allocating.
+        if (s == Status::ERROR_GATT)
+            lastLogNotifyFailureMs.store(millis());
+    }
+};
+
 class NimbleBluetoothSecurityCallback : public BLESecurityCallbacks
 {
     void onPassKeyNotify(uint32_t passkey) override
@@ -1005,6 +1029,9 @@ void NimbleBluetooth::setupService()
     static NimbleBluetoothFromRadioCallback fromRadioCallbacks;
     FromRadioCharacteristic->setCallbacks(&fromRadioCallbacks);
 
+    static NimbleBluetoothLogRadioCallback logRadioCallbacks;
+    logRadioCharacteristic->setCallbacks(&logRadioCallbacks);
+
     bleService->start();
 
     // Setup the battery service
@@ -1056,6 +1083,12 @@ void NimbleBluetooth::sendLog(const uint8_t *logMessage, size_t length)
     if (!isConnected() || length > 512) {
         return;
     }
+    if (!logRadioCharacteristic) // BLE may have been torn down; never notify a freed characteristic
+        return;
+    // The host rejected a log notify recently, so the mbuf pool is under pressure. Drop this line
+    // rather than spend a buffer the fromNum doorbell needs; see kLogNotifyBackoffMs.
+    if (Throttle::isWithinTimespanMs(lastLogNotifyFailureMs.load(), kLogNotifyBackoffMs))
+        return;
     logRadioCharacteristic->setValue(logMessage, length);
     logRadioCharacteristic->notify();
 }

variants/esp32/esp32-common.ini

@@ -291,7 +291,12 @@ custom_sdkconfig =
   CONFIG_BT_CTRL_BLE_MAX_ACT=2
   CONFIG_BT_CTRL_SCAN_DUPL_CACHE_SIZE=10
   CONFIG_BT_NIMBLE_WHITELIST_SIZE=1
-  CONFIG_BT_NIMBLE_MSYS_1_BLOCK_COUNT=8
+  # msys_1 is the only pool GATT uses: every notification and ATT response allocates through
+  # os_msys_get_pkthdr(0, 0), which always resolves to the smallest pool, and chained buffers stay
+  # in it. 8 blocks left too little headroom for a notify burst (#11245), so restore the IDF default
+  # of 12 -- +1KB, and still well under the pre-trim footprint. Raising msys_2 instead would do
+  # nothing here; nothing on the notify path ever allocates from it.
+  CONFIG_BT_NIMBLE_MSYS_1_BLOCK_COUNT=12
   CONFIG_BT_NIMBLE_MSYS_2_BLOCK_COUNT=8
   CONFIG_BT_NIMBLE_TRANSPORT_ACL_FROM_LL_COUNT=8
   CONFIG_BT_NIMBLE_TRANSPORT_EVT_COUNT=12