Note: This is a re-do of pr #427, but based on the dev branch.

I would like to use this PR to open a dialog into integrating heavier use of C++ features into the codebase. Comments are encouraged. But please send any comments about what I should or should not be working on directly to me instead of commenting here.

Status as of 2021-05-10: I believe the code sufficiently demonstrates concepts that could be used in further refactoring. I believe the code to be bug-free. , but not complete, as both old and new ideologies coexist for discussion and testing purposes. More test cases are needed for edge cases that I have as yet not learned about.

Points for discussion:

1. Implementations in header files: Much of the code I have seen contains little implementation in .cpp files and most in .h header files. The disadvantages of this approach are (1) increased compile times and (2) delicate dependencies in linking libraries or executables. Moving the implementations to .cpp files does have disadvantages as well, such as objects compiled with different parameters can cause different (sometimes hard to diagnose) errors, but it is my opinion that the benefits outweigh the dangers.
2. Use the standard library where it makes sense to avoid platform-specific code. Two changes highlight the benefits here. Mutexes (std::mutex insted of pthread's version), and lists (std::list vs ptr-to-ptr lists).
3. Remove use of pointers where possible (i.e. pass references if possible, const references are even better), use reference counted pointers instead of raw pointers. The std::list vs ptr-to-ptr is an example here as well.
4. Declare necessary variables when you need them, not at the beginning of the function. This often makes the code easier to read.
5. Use exceptions where it makes sense. If the code is littered with if statements for error checking, consider using try/catch. This can reduce the code you need to write, as well as provide a performance boost in some instances if done correctly.
6. Use namespaces. Instead of starting each method name with komdo_, consider using namespace komodo. This reduces name collisions within the codebase (we know what an "event" is in komdo, and don't have to worry about puting "komodo_" in front of it, or a UI event having a name collision with it). This also often makes using your code as a library less cumbersome.
7. Use bool if you only need true/false instead of other integrals. This makes your intent clear.
8. Comment things that may be unclear. I personally use doxygen style comments on top of my functions. I hope everyone can understand my code by reading it, but sometimes it is very inconvenient to do so. Of course the evil side of comments is they are often stale or inaccurate. But the intent often remains.
9. Push implementations to where they belong. A "notary event" needs to be serialized. It is probably best that the code to do so reside close to the definition of what a notary event is. Every serialized "event" has a header, so this is probably a good time to use a hierarchy of "notary_event is an event, and knows how to serialize itself". Now reading or writing it to disk only requires code to tell a notary event to serialize/deserialize itself. The implementation code stays centralized and out of the way.
10. Refactor a little at a time. Knowing then what is known now, everyone would love to rewrite pretty much everything we've ever written. Avoid the urge. Bite-sized subsystems can be tackled. Eating the whole elephant will take time. The majority of the komodo_events.h file breaks point 9 above. I'd love to get rid of it, as well as big chunks of komodo.h for the same reason. But that would make testing and comparing the existing implementation with the refactor too much to take on in this round. So they will remain until they are no longer needed.
11. Header files should be independent. Include all the #include files necessary for the .h. This makes chasing down dependencies less of a problem at the expense of a little compile time. Use #pragma once to help with this.

The above points are simply opinions. I am not here to start wars. If the team decides that any (or all) of these are a bad idea, I'll happily work without using them. Explaining why they are a bad idea helps everyone, but is not required.

Reading suggestions and References:

• Migrating Legacy Systems
• Komodo Contributing Guide (includes recommending established standards such as Google's or Bjarne Stroustrup)
• Bitcoin Contributor Readme
• Bitcoin Developer Notes and Coding Style Guidelines