Add locks when querying chainActive

[jmjatlanta]

Fixes Issue #482

The std::vector vChain within the CChain class is not thread safe. Various methods modify and query the vector with no synchronization. This fixes those found during testing.

TODO:

• Check for deadlocks. Clang's static analysis tools may help.
• Check for other AssertLockHeld failures (i.e. the wallet), and turn into an issue. (not part of this PR, just a reminder)

[jmjatlanta]

In the last few commits, I have updated the threadsafety annotations to work better with more recent versions of clang. With that, I have run the analysis and found the areas for cs_main that need locking.

See this file and search for warning:. There are 396 hits, some of which do not apply. The warning mutex 'm' is still held at... is a false positive.

For the majority of cases, we will need to determine if we should

1. Already be locked further up the stack
2. Lock for the duration of the call
3. Lock for a portion of the call
4. Lock only for the chainActive call (additional class methods could make this easier).

I am assuming for now we will continue to use exclusive locking. Small changes to the instrumentation will be necessary if we move to shared locking.

Trying to fix all these warnings as part of this PR is probably "scope creep". A separate effort is also needed to add instrumentation for other (non-cs_main) mutexes.

[dimxy]

Great that lock held asserts are added.
I can see there are still many places where functions like komodo_chainactive, komodo_chainactive_timestamp etc are called without locks so we need to continue work on improving synchronisation in the codebase (in next PRs)

[dimxy]

good to test the code for some time after merge into dev

[tonymorony]

these changes implemented in combined PR: #559