Fix MQTT discovery

[OttoWinter]

Description:

After looking into #16968 a bit more (so that the device registry will be possible for MQTT entities 😉), and finding out what exactly was causing the problem, I think I now have a working fix that does not modify any core code.

The problem was that the MQTT discovery callback would get called multiple times while the platform was still being set up. Inside async_forward_entry_setup and then in async_setup_component a new task is created for the loading of each component. Until the config entry is fully forwarded, another MQTT discovery message might come in and call async_forward_entry_setup another time, triggering the bug in #16968

Suppose a discovery message for a switch.mqtt comes in. The platform needs to be loaded and the config entry is forwarded via async_forward_entry_setup. async_forward_entry_setup however adds new tasks to the event queue and the key is only added to CONFIG_ENTRY_IS_SETUP after that newly created task is completed.

During that time, another discovery message for another switch might come in. Nothing is in CONFIG_ENTRY_IS_SETUP yet so the platform is loaded again, triggering #16968

This PR shuffles the affected line around and I have since not been able to reproduce the race condition. Because this code fragment is now executed in one go and lives inside the event queue, I think the race condition should be fixed.

Related issue (if applicable): fixes #16968

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[balloob]

One potential race condition could be that the config entry set up is not yet listening to dispatched signals.

This fix is a good start though.