Correct actions order in async_setup_entry

[Lurker00]

The problem I was facing for a long time:
Right after LocalTuya start or restart, some random entities may have Unavailable status, until they are updated from corresponding devices.

The reason:
The status of an entity can be updated by LocalTuya means only after the entity has been registered in HASS, i.e. after LocalTuyaEntity.async_added_to_hass() method was called, which registers _update_handler(). But async_setup_entry() first created async tasks to connect to devices, then waited for the first successful connect, and only then called hass.config_entries.async_forward_entry_setups() which creates entities instances in HASS. async_connect()->_make_connection() may change device's entities statuses, but the changes are not passed as they should.

With the recent global changes in device initialization and connection order, Zigbee and BLE sub-devices are connected with a delay mostly enough to propagate status updates, but WiFi low power sensors (e.g. T&H sensor) always have Unavailable status, because at the time of its first _make_connection() call, which starts with

hass-localtuya/custom_components/localtuya/coordinator.py

Lines 172 to 173 in 284ebb5

	if self.is_sleep and not self._status:
	self.status_updated(RESTORE_STATES)

didn't lead to _update_handler() call, but made self._status not empty, preventing calls to self.status_updated(RESTORE_STATES) during further connection attempts.

The solution:
Creating of async_connect() tasks is delayed until entities are fully initialized by HASS. There is no a reason to wait for the first successful connection here. So, first, LocalTuya objects are created, then HASS objects are created, and only then startes the connection process.

Now it works as expected. This was the last known to me problem with LocalTuya engine 😄

[xZetsubou]

The reason I made it wait for at least one device it was due to some devices that only accept one connection if the integration was reloaded twice quickly the entities may not dispatch the status until reload or device status update, so I made a moments of wait.

However many things changed so If the issue somehow shows up an await should be added.