Asynchronously run software updates discovery when applying settings

[nelsonkopliku]

Description

This PR makes sure the software updates discovery for all the hosts in the system is triggered asynchronously on save/change settings.
Also, in order to avoid unwanted side effects the Discovery state gets cleared right before triggering async discovery, so that the state gest reconstituted with new settings.

Keeps the save/change settings operation quite immediate not impacting performance when discovery needs to be executed for many hosts.

How was this tested?

Automated tests.

[arbulu89]

Nice!
Looks good

[arbulu89]

Maybe we want to add some after to receive so it doesn't hang forever if the process doesn't end,
Maybe some optional timeout value

[nelsonkopliku]

Here we go e3b075b.

[nelsonkopliku]

thanks @arbulu89! I am still testing a few things out 'cause I noticed a weird behavior, like the thing seems to still be blocking in a start_child and so I was gonna try with just async.

Besides this I was also thinking that maybe we can make async also the discovery happening in SoftwareUpdatesDiscoveryEventHandler.
Since there is only 1 instance of that listener running, every discovery being triggered by a SoftwareUpdatesDiscoveryRequested event would wait for the previous to finish.

What do you think?

[arbulu89]

Besides this I was also thinking that maybe we can make async also the discovery happening in SoftwareUpdatesDiscoveryEventHandler.

I don't find it really needed there. In that scenario, we are not in a rush to make things happen, and besides, once the authentication and requests are separated, it will only "block" the 1st call, and from that point on, all the queries would be done in parallel.
I wouldn't add more async tasks there, as we don't really need that feature (and more, if it is solved in suma code)

[nelsonkopliku]

I am not sure the following is completely correct 🤔

from that point on, all the queries would be done in parallel.

What happens in Discovery.discover_host_software_updates (a discovery for a specific host) would still be awaited on for the listener to continue handling the following SoftwareUpdatesDiscoveryRequested event, also when we have only the auth blocked in a genserver linearization.

But maybe I am missing something.

Anyway, I won't change what happens in the listener for the time being.

[arbulu89]

@nelsonkopliku Let's start from the beginning.
That event handler by now is just sequential, so it will handle all the events one by one.
What I mean with the "parallelization" is that if you change the event handler to work concurrently, if 2 events arrive at the same time, if the authentication is not done, one of the events will start the authentication, and the other will wait there (as the genserver makes this happen).
Once the authentication is done, the first event will just do the queries for the system_id, etc, and the 2nd as well, because the queries are not part of the gen server anymore, so there is not blocking.

If the authentication fails in both, well, both will fail at the same time