The error log is currently somewhat noisy due to the presence of expected errors, such as WT_NOTFOUND from cursors, e.g., __curfile_search. We should find a way to remove such entries after it has been determined that the error can be ignored.

Here is one way we can do this:

1. Before calling a function whose results we might want to ignore, place a "clear mark" into the error log.
2. At the end of the function, if the returned error can be ignored, clear all log messages up to the last "clear mark."

Perhaps we can do this by leveraging WT_ERR_TEST and WT_RET_TEST (and their variants), which are used in most places where an error value can be ignored. We can also provide a way to do this for other scenarios, e.g., where a function calls WT_ERR_NOTFOUND_OK(ret, false) without the actual function call inside.

However, note that this would have to be rather efficient, because we would be placing clear marks and removing error messages during the main execution path, and not just during the (presumably slower) error paths.

One way to do this would be to keep a stack of error counts inside WT_ERROR_LOG, and then:

• Placing an error mark would mean pushing a 0 onto a stack of counters, and adding an error to the log would constitute increasing the latest value on the stack.
• Clearing messages up to the clear mark would mean removing the given number of messages by modifying the tail and count fields inside the WT_ERROR_LOG struct, and popping the latest count from the stack.
• Keeping such error messages could be implemented by popping the last count from the stack, and adding it to the value that is now on top of the stack.

Credits to y.ershov@mongodb.com for coming up with the overall architecture for this approach.