Fix #4046 Details below:

[geeksville]

Informed by the discussion in the bug and the code in 'that other branch'
the fix was clear. Just set a flag if we start handling a write, and
use that flag to guard the long write complete call.

[geeksville]

fix #4046 (oops git didn't tag that issue)

[vicatcu]

Just want to confirm that I have been using this PR as a patch against 1.0.4 successfully, and would endorse / encourage its acceptance

[geeksville]

@vicatcu btw - just in case it is useful to you as a fellow bluetooth on ESP32 traveller: I eventually decided to switch our project to NimBLE rather than the Bluedroid implementation included in arduino-esp32 (see my other PR to this project to make Bluedroid optional). Switching is possibly more hassle than you want to deal with, because you need to rebuild the ESP-IDF libs (or use the prebuilds we use on our project - I guess - though I'd rather not have to keep our own fork). But at least in my case it seemed eventually necessary because the Bluedroid implementation inside of ESP-IDF doesn't properly handle clients that are using RPA (which now means iOS and Android clients). I couldn't really ask our users to keep re-pairing their clients to the devices, so I bit the bullet and switched to the newer stack.

I'm super glad I did - because reliability is way up (now perfect - with a few hundred reported clients). More info here: meshtastic/firmware#296

[vicatcu]

@geeksville many thanks for the pointer, got some other fish to fry at the moment, but something to consider in the future. Is there are migration guide or anything like that?

[geeksville]

alas no. It works for my project but alas, I can't sign up for writing a "Bluedroid to NimBLE migration guide" because same problem of a super overfull queue of tasks ;-).