Vehicle Module Priority - Preference local BLE over API

[ngardiner]

The idea of this branch is to introduce module priorities, which would allow us to overlap the TeslaBLE module over the top of the TeslaAPI module, so that commands like start/stop charging, wake, set charge limit etc would first be sent out via BT, and we'd look for indications in the response that confirm that the command was sent.

If this fails, it would fall back to the next priority module, the API. It's possible we could slot another module in-between these for the Tesla Fleet API - eventually the owner-api will go away and it will just be a no-op, this is my view of how we can untangle / stack technologies as Tesla deprecates the API we've depended on for a while now.

• Implement prototype static module priorities to create initial priority order
• Implement prototype fallback code for calling start/stop charging via this logic
• Track the performance of modules to allow us to visualise how this is operating
• Implement a better way of showing the statistics
• Consider if instead of just falling back to the next priority down, we might be able to do something like assign a multiple for retry logic - eg every 10 priority = 1 retry in the event of failure.
• Find a more appropriate way to implement this - perhaps a proxy Class which automatically routes methods in priority order
• Replace functions outside of start/stop charge

Regressions:

• Changes to car_api_available to replace charge argument with task needs to be updated in other locations

Tests:

• Backwards compatibility (what happens if BLE is not loaded?)