Add seperate setup flow to coordinator

[WebSpider]

This alters the coordinator setup as follows:

• When doing a data update (poll), we make a distinction between a regular update and one being made while the MySkoda integration is being setup
• During setup, we require the get_user() and get_vehicle() call not to return any unignorable errors
• During setup, we tell HA to schedule the MQTT connection for when we are done setting up
• During regular polling, we check if MQTT connection is still present, and try to reconnect if needed

This should allow the integration to succesfully set-up, even if MQTT is unavailable, instead of blocking HA startup for 1h.

[WebSpider]

Converted to draft since this probably needs a different approach

[dvx76]

Why does this need a different approach?

I'm trying to understand how the coordinator is involved during the setup (ConfigFlow?) i.e. how does _async_update_data end up being called during the setup?

[WebSpider]

Why does this need a different approach?

The approach that is currently in this draft is mostly incomplete and has corner cases for multiple vehicles, integration reloading

I'm trying to understand how the coordinator is involved during the setup (ConfigFlow?) i.e. how does _async_update_data end up being called during the setup?

ConfigFlow is the configuration of the integration. Once the integration is configure, it can be setup. Those are two different things.

In setup, async_setup is called in __init__.py, which instantiates and inits the coordinator(s).

Have a look at the coordinators parent class, they are partially overriden by us only

[WebSpider]

My idea is to only request data during first setup of coordinator that is needed for the actual initialisation, and then do a normal data pull.

This should hopefully make integration setup a lot more robust