Unify critical session running in hls

[soulomoon]

see #4251
What's done

1. add Development.IDE.Core.Thread to provide common api to run a woker thread
2. rewrite runWithDb using the Development.IDE.Core.Thread
3. add session loading thread and session restart thread using Development.IDE.Core.Thread
4. send session loading runs to session loading thread
5. send session restart runs to session restart thread

The above modification ensure the shutdown handler can cancel the session loading and session restart. And hence we would have a more correct shutdown behaviour. Potentially make the test less likely to hang.

[michaelpj]

I think a more typical name for something like this would be a "work queue" or "job queue".

[michaelpj]

I guess this kind of looks like two separate things to me:

1. A domain-specific withResource which creates the resource and passes it to a continuation.
2. A standard "worker queue"

My instinct is that we could focus on defining the worker queue, and just leave the creation of the resource, where necessary, to the call site. Indeed, many of the call sites don't create a resource at all! I think we could then quite naturally write:

withMyResource $ \resource -> withWorkerQueue (\arg -> doSomething resource arg) $ \queue -> ...

or something?

[soulomoon]

Make sense, let's implement withWorkerQueue instead to see if that would make better sense

[michaelpj]

This looks better, makes sense to me.

I do wonder: if we are using blockRunInThread, then it looks like it's pretty much identical to having a resource that's guarded by a lock, and then having the waiting threads block on acquiring the lock. If we put work into the queue and the move on so it can be executed asynchronously, then it is different. But if we immediately block and wait then there's no real effect of it happening in another thread!

[soulomoon]

it's pretty much identical to having a resource that's guarded by a lock

yes, with a bit different, enqueued actions would not be cancelled even if the thread start it is cancelled.

It reminds me of something, we might probably want to limit some of the queue size to 1, so the waiting to enqueue action can be cancelled when we are doing shakeRestart. Then less likely a duplication actions would be run for the sessionLoadQueue
But maybe in another PR, we might need to come up with some design, such as we might need a bit wrapping to do over TQueue and TMVar if we do it this way.