Release can deadlock if node cache is too small

[HerbertJordan]

This issue was encountered in a CI test testing the releasing of accounts with large states. The recursive release operation may keep write locks on nodes that get scheduled to be flushed.

A temporary fix was the increase of the node cache. A future improvement may perform the release iteratively, not holding locks on nodes for long durations.

[HerbertJordan]

The number of locks held by the asynchronous node release worker should be limited to the maximum trie height since it utilises a depth-first iteration through the trie that is released. Furthermore, any node that is accesses during the release is accessed through the getWriteAccess function, which causes the accessed node to be at the begin of the node cache, far way from the end where nodes are flushed and released.

Thus, given that tries are at most 30-40 nodes high, and caches contain several thousands of nodes, nodes to be flushed should not bot be blocked by the background node releaser.

Ultimately, however, this is related to #686 describing that the node cache is an inherent limitation on the working set, which includes the set of nodes accessed during releases.

[HerbertJordan]

With #780 stress tests for deleting large accounts have been added, and so far no more issues for those situations have been identified in nightly builds.

[HerbertJordan]

I am closing this; obsolete;