* Implement mutex ownership and use it to check potential upward lock gathering
* Don't hold instance lock and call willEnterHierarchy/didExitHierarchy of ASDisplayNode
- This can cause deadlocks (e.g #2605) if subsequent methods, that are implemented by developers, walk up the node tree.
- This is a way to keep the optimizations introduced in 9e87813 while making sure the locking situation is a bit safer.
* More lock ownership assertions in ASDisplayNode
* Document main thread contract of -clearContents
* ASNetworkImageNode shoud not call setNeedsPreload while holding instance lock
- This helps to avoid potentially deadlocks caused if the node (esp in case it's a subclass of ASNetworkImageNode) walks up the tree in didEnterPreloadState, for example to build logging context.
* ASVideoNode should not call setNeedsPreload while holding instance lock
- This helps to avoid potentially deadlocks caused if the node (esp. if it's a subclass of ASVideoNode) walks up the tree in didEnterPreloadState, for example to build logging context.
* Don't hold instance lock for the entire insert subnode operation
- The recursive lock should not be held throughout `_insertSubnode:atSubnodeIndex:sublayerIndex:andRemoveSubnode:`. The method instead should manage the lock itself and acquire it as shortly as possible. The reason is that this method calls many methods outside the scope of `self`. `[subnode __setSupernode:self]` is especially troublesome because it causes the subnode to migrate to new hierarchy and interface states, which triggers `didEnter/Exit(.*)State` methods. These methods are meant to be overriden by subclasses. Thus they might walk up the node tree and potentially cause deadlocks, or they perform expensive tasks and cause the lock to be held for too long.
- Other methods that call this method should release the lock before doing so.
* Lock getter and setter of `synchronous` flag
* Address comment in ASVideoNode
* Add main thread assertions to methods that change asset and assetURL of ASVideoNode
* Explain CHECK_LOCKING_SAFETY flag
* More thread and locking assertions in ASVideNode
- It's not safe to call `-[subnode __setSupernode:self]` while holding instance lock of soon-to-be supernode (e.g `self`).
- It's also not safe to call `[subnode __setSupernode:nil]` while holding the instance lock of the old supernode (e.g `self`).
- did(Enter|Exit)(.*)State methods are always called on main. Add main thread assertions to indicate that.
* Minor change in explanation of CHECK_LOCKING_SAFETY flag
Locking was not quite right here in a certain case where the transaction leaves after other references
were removed. Will restore this optimization in the future with more time to analyze.
This reverts commit ee524f497d0692a2c0c6ea39bd3840183a00f3ed.
Summary:
* Moves ASThread.h from Private to Public visibility
* Moves ASThread.h from Private/ to Details/
* Changes public #imports from "" to <>
Test Plan:
```
#import <AsyncDisplayKit/ASDisplayNode+Subclasses.h>
#import <AsyncDisplayKit/ASControlNode+Subclasses.h>
```
