Improve update check

[litetex]

This should address 2 problems from #953 (comment)

1. Use the non-critical/download IO Thread pool to start the overall update process (checkForUpdates0)
2. Don't wait for all started update checks in checkForUpdates0 to finish - This is not needed and just blocks the underlying thread

It might also be helpful to backport these changes

[gniftygnome]

Frankly, I am not as clear as I would like to be on how this works, and lacking in time to understand it. However, now is the time for some risks since we are still very alpha for 26.1. I am going to merge it and deal with whatever happens later when it happens.

[litetex]

Frankly, I am not as clear as I would like to be on how this works, and lacking in time to understand it.

Uhm it works by 1. using a different thread pool and 2. not calling the blocking close method but using the non-blocking shutdown instead. That's the PR in a nutshell xD

[gniftygnome]

Uhm it works by 1. using a different thread pool and 2. not calling the blocking close method but using the non-blocking shutdown instead. That's the PR in a nutshell xD

That's a functional description of the changes, which are more extensive than that description might lead a person to expect. A standard try-with-resources which wrapped the entire function is replaced with a different approach. Also while you may know the purpose and function of the various thread pools, to somebody who does not it is quite opaque. My comment merely indicated I had to take it on faith this new implementation is correct and that if it isn't, hopefully that will come to light during the alpha stage of ModMenu for 26.1. If I backport it, that will be after it's been in 26.1 long enough I'm comfortable it's not introducing new bugs.

[gniftygnome]

And #1016 is a pretty good example of the kind of thing I was generally concerned about. :)