refactor csg_tree to avoid blocking

[pca006132]

The current csg_tree implementation will hold the lock until the underlying object is completely evaluated. If the lock is already taken, the thread will not be able to proceed and we will lose 1 worker thread in our thread pool. This behavior will occur when two parallel boolean operations both depend on a single object that takes a long time to evaluate.

Ideally we should refactor csg_tree to avoid using such blocking construct internally. We can change to an async style (internal) API, put the task into a top level watchkeeper when the task is waiting for the result of some other operation and it can do nothing. The top level watchkeeper should put the task back to task_arena when the task is ready (received an event).
The top level watchkeeper implementation can depend on TBB, because there is no blocking issue when we are running in a single thread.

[pca006132]

Thinking about it, it might be common to create a mesh and not use it as boolean operand. E.g. boolean result that are exported, used for compose, transform, hull, offset (not yet implemented), smooth. For these cases, computing the collider will waste quite a bit of time and memory. Maybe we can make the collider lazy as well.

What do you think? @elalish

[elalish]

I had considered this - at the time I figured it would be a bigger waste to create a collider multiple times for copies of meshes that get used in Booleans. After all the work you've done with the CSG tree, I'd guess it would be easier now to implement proper lazy evaluation without duplication. I'd definitely be in favor of that, so long as we can retain the cheap updates for simple transforms.

[pca006132]

Yeah it would be something similar to our csg tree, which uses shared pointers to avoid duplicating work. Cheap updates are still possible that way.