💪 Decreasing the frequency/quantity of BLE scans for better performance

[JGreenlee]

The quantity of background/bluetooth_ble entries is staggering and likely much more than we need.

In the April 24 dump of dfc-fermata, my user has 54208 background/bluetooth_ble entries. That would have been from a bit over 1 week of testing, since I believe we rolled out the alpha on the 15th or 16th. By comparison, there were only 14003 background/location entries during that timespan. That was on an iOS device.

We should look at the differences between iOS and Android and try to:

• limit the number of scans that occur on the phone (for battery drain considerations)
• limit the number of scans that get recorded to DB (for scalability considerations on the server while processing)

[JGreenlee]

@the-bay-kay recently addressed extraneous transitions (https://github.com/e-mission/e-mission-data-collection/pull/230), which will also help performance but I don't think it will limit the number of background/bluetooth_ble entries

@shankari found that iOS does not offer a way to adjust the scan frequency during ranging: https://developer.apple.com/documentation/corelocation/cllocationmanager/3240607-startrangingbeaconssatisfyingcon?language=objc So it may be necessary to start and stop ranging throughout the trip (for example, maybe we range for 10s every 1 minute, and then maybe we record a subset of those scans)

@louisg1337 I do not know what performance is like on Android currently