Bluetooth Devices disconnect upon bluetooth sensor switch

[posytive]

Fixes #404

Draft because:

• some tests need to be fixed
• some tests need to be added
• mocks need to be improved (to simulate bt on/off scenarios)
• (optional) mock can be moved to a different module

[dasdranagon]

For me looks fine. I would only remove commented code

[codecov]

Codecov Report

Attention: Patch coverage is 47.22222% with 19 lines in your changes missing coverage. Please review.

Project coverage is 48.11%. Comparing base (b6234ec) to head (3a9557c).
Report is 1877 commits behind head on develop.

Files with missing lines	Patch %	Lines
...etooth/src/commonMain/kotlin/device/DeviceState.kt	47.22%	18 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #405      +/-   ##
=============================================
- Coverage      48.38%   48.11%   -0.28%     
  Complexity       219      219              
=============================================
  Files             62       62              
  Lines           2412     2436      +24     
  Branches         310      318       +8     
=============================================
+ Hits            1167     1172       +5     
- Misses          1108     1126      +18     
- Partials         137      138       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[avdyushin]

Here is something to discuss. This state represents Device when Bluetooth is turned off by the system. On iOS it means all services/characteristic objects are invalid (we can't read/write from them anymore). Also as far as I know Identifier for Bluetooth peripheral autogenerated by system at the time of discovery (compare to Android, where it's always MAC address of the device). We have to check if keeping Identifier somewhere and doing connection/reconnection/bluetooth/on/off after next scan we can access to the same device by this Identifier.

[posytive]

Good point, I haven't thought of that cause I din't know about this requirement for ios.
Is true that I have been having re-connect issues on iOs for a project using this lib, at this specific branch, but I was blaming a different part of the code for it.
(we disabled automatic reconnection on that project, due to un-stable behaviour in general)
Interesting to know: I should now check this again, following on what you pointed out.

In my understanding, was enough to make sure Not to save services/characteristics the same way the original code was already doing upon other types of disconnection.
You can see in this file, at line 346, that internal val noBluetooth = suspend {} function passes a null for those.
In my understanding, that should have been enough to guarantee that re-connecting would fetch services/characteristics again.

Long story short, I will check the feasibility/impact of keeping Identifier in the state.
Is a bit unfortunate that I don't have with me the device we use on the other project, but I will check what I can do using our own example.