Event notifications and Debug Log callback

[TimEvens]

The API should expose two methods for event/logging that does not require the application to implement a specific third-party library, such as spdlog. The application should be able to use any method/library they choose for logging.

A change is needed to the API to add callbacks for error level events and debug logging.

Error level events are for conditions that would normally be a log message with a severity of less than INFO.

Debug logging is needed for the support of the library when things don't work as expected. For example, user files an issue regarding client disconnects during interop but the disconnect does not indicate the exact reason for interop failure. The user could enable debug logging to expose detailed logging which could then be attached to the issue. This would then allow libquicr developers to root cause the issue.

Client and Server API should add the following callbacks:

1. EventNotification(Event event) - Callback notification on event, which could be any severity INFO or less
2. LogDebug(std::string& log_message) - Callback notification of debug log messages. This method only provides a formatted string that the application should (if desired) write out to somewhere to record debug logs.

Event struct should contain the following:

• Severity enum - EMERG=0, ALERT=1, CRITICAL=2, ERROR=3, WARNING=4, NOTICE=5, INFO=6
• Code enum - This should be a unique error code for the event
• Message string - This should be a simple string describing the code
• Map of Key/Values - Meta data should be provided along with the event. Meta data can be any key=value pair. It should always be of type string, string.

In general, events should be specific and meaningful where action is likely required by the calling application. Info events should be sparingly used. Often, info would be classified as debug.

[fluffy]

I don't know ... here is my 2 cents.

1. Most libraries don't have anything like this. The error codes, status returns, way to get internal metric counters / state should be enough for applications using the library. Its a bit different if you are developing or changing the library.

2. It is really hard to do this and have it be fast, even if no call back is provided, it still can be a big performance hit. Most logging libraries try to be compiled out for production stuff where they do not even have the overhead of checking a variable.