Don't capture synchronization context in DiskWriterQueue

[alexbereznikov]

This addresses #2446

Task.Factory.StartNew tries to use task scheduler from the current task, so TaskScheduler.Default needs to be passed here.

[pictos]

I can see the value of not capture the syncronization context, but this will be a breaking change. From the linked issue, it's caused because your project uses a custom SyncronziationContext, but that doesn't happen on UI frameworks, that implements its own syncContext, so I that doesn't prove that the issue is in your SyncContext implementation and not on LiteDb?

[alexbereznikov]

@pictos As I described in related issue (#2446), breaking change was introduced after 5.0.17 - Task.Run (which uses default task scheduler) has been changed to Task.Factory.StartNew (that uses a current task scheduler by default). More precisely, breaking changes were made in this commit - f21cd84

So this PR aims to revert this breaking change, not to introduce one.

Regardless of whether our custom context is implemented correctly, I don't think it is a good idea to execute writer queue on a captured context (e g UI context). I would say, it rather highlights the issue.

[pictos]

So, looking more closely to the implementation I strongly believe that the issue is more than having it capturing the current task's TaskScheduler.
The task is being created with LongRunning flag, and uses an async delegate, and you may know that those two doesn't fit togheter.

So the first thing we should change here is to make the ExecuteQueue a void method, and block the created thread on the async operations or rethink all this engine, which I believe will not be done on this PR if we choose this path.

edit: Did a PoC using the main implementation and it will not flow the UI context, adding the TaskScheduler or not will not change the behavior, will just go throw UI thread if you pass TaskScheduler.FromCurrentSynchronizationContext(), so I would say that your PR will not fix the issue at the end

[pictos]

After talking with @mbdavid, I could understand the idea behind this member. So the fix is something completely different from your implementation.

No matter if you pass the TaskScheduler as parameter or not, it will not run on the UI Thread. The fix is making the ExecuteQueue method a void method and all the implementation should be a block code, that's not use any asynchronous API.

Also, for improvement, remove the lock object on the task instantiation and use an interlockedExchange method to verify if there's a need to create a task.

With that the code will behave as expected, it will run on a deticated thread and will not touch any kind of syncContext, taskScheduler or threadPool Thread.

Let me know if you want to perform these changes, otherwise I'll do it. And thanks for your hard work so far❣️