Improve suma authentication concurrency

[arbulu89]

Description

Change the SUMA interaction module to use the GenServer only to handle the authentication, not the whole sequence of queries. This way, only the authentication is a "locked" process, and all the other requests can happen concurrently.

The other "small" improvement is that the when we do a "batch" discovery (on saving SUMA settings for instance), we just authenticate once, and use that data for the rest. Otherwise, as the auth is still sequential, it would've been tried for each individual host, and when the user/password are wrong for instance, this could take a lot (5-10 seconds per host).

It is just an improvement of performance in reality, nothing else.
As things happen in the background the user might not even notice things (except, some toast are happening faster, etc).

How was this tested?

Unit tests updated, and I have tested manually with our own SUMA instance.

Next:
The discovery when we save the settings must happen async, so the patch is not holded there for a while (which can even create timeout issues)

[gagandeepb]

I brought this up during a chat with @nelsonkopliku earlier today, but I wonder if it would be interesting at some point to have something like Cachex available to enable caching of certain frequently accessed state ? We would also get a nice interface for TTL, expiry/refresh, warming etc. This would also mean not having to rely on a GenServer for frequent state reads from different execution contexts (I'm not fully sure if that is the case with the state of the GenServer here, though).

[arbulu89]

Thank you for you comment @gagandeepb
I guess that we could use any k/v store for such a things, but keep in mind that the purpose of the genserver is not only that. It plays the role of having a centralized authentication entry point, so we can keep this "locked/sequential", and as it is an operation that can take some few seconds, we still need to handle it.
At the end, we are doing OS level operations writing/changing files, which we don't want to run in parallel.

[nelsonkopliku]

Hey @arbulu89 thanks for this!

Besides some cosmetics my main comment is about keeping what you have extracted as authenticated = setup() inside the auth flow.

[nelsonkopliku]

LGTM @arbulu89, thanks!

[dottorblaster]

Great work! I really like this approach 👍