Tasks are not guaranteed to be removed when a log manager is torn down

[bliptec]

Also related to #382, there is a potential for upload tasks to not be canceled when a log manager is torn down. In the worst case, this could manifest as a task executing after the log manager has already been torn down. One option is to make task cancellation a potentially-blocking operation, which could impact the API surface's performance. Alternatively, there needs to be a way to associate tasks with a log manager, so that all the tasks can be properly cleared from the worker thread when the log manager is destroyed.

This may overlap with #271

[bliptec]

Currently, this doesn't seem to be a significant concern. #382 should resolve almost all of the task cancellation issues still being observed in Edge

[maxgolov]

I like the 2nd option better, where we could associate each task with its parent LogManager. When LogManagers receives DONE task (as indicator that no more tasks are incoming), we should scan the queue for all tasks that belong to that LogManager and cancel.

However, some tasks are mandatory, e.g. Flush() on shutdown - we have to potentially wait for that task completion to avoid data loss. In a model where Deferred Callback Handle holds a ptr (or weak reference) to task, the code may know that this specific task requires infinite wait (UINT64_MAX or whatever other max duration timeout value if we use STL duration type). Basically in those cases the code should block on cancellation BEFORE we emit the DONE task... For the second part -- isn't this the logic that we already implement today? (possibility of a manual infinite wait on deferred callback handle).