Clean up lockorder data of destroyed mutexes #7846

The lockorder potential deadlock detection works by remembering for each lock A that is acquired while holding another B the pair (A,B), and triggering a warning when (B,A) already exists in the table.

A and B in the above text are represented by pointers to the CCriticalSection object that is acquired. This does mean however that we need to clean up the table entries that refer to any critical section which is destroyed, as its memory address can potentially be used for another unrelated lock in the future.

Implement this clean up by remembering not only the pairs in forward direction, but also backward direction. This allows for fast iteration over all pairs that use a deleted CCriticalSection in either the first or the second position.

Hopefully this fixes #7470.

Thanks! I lack the understanding of this code to be able to review it, unfortunately this makes the code even more complicated. Luckily it's only active in debug mode (--enable-debug) anyhow.

utACK if it fixes #7470.

@laanwj Added a PR and commit description that explains the change and rationale.

Nice! LGTM. utACK 5eeb913d6cff9cfe9a6769d7efe4a7b9f23de0f4.

@sipa OHH I get it now. So sync.cpp keeps track of locks after they are unlocked. They are simply never cleaned up. I had assumed this was only keeping track of active locks, so I didn't understand why locks would be deleted that were still held somewhere. But well in that case this fixes a memory leak too! tACK 5eeb913