Additional logging for errors in ByteBufferAsyncProcessor

[Friedrich von Never (ForNeVeR)]

Since exceptions in this method may indicate a fatal error in the logging subsystem, the only place we're able to log them is LogLog.

[Sergey Kuks (sergeyQx)]

(Note that rethrowing with “throw;” instead of “throw e;” would “preserve the corrupting-ness”, meaning the whole process would probably be torn down as the re-thrown exception continued to propagate.)

[Sergey Kuks (sergeyQx)]

Serge Baltic (@hypersw) suggests to use throw new Exception(e) to preserve the original callstack

[Friedrich von Never (ForNeVeR)]

For this case, I don't think that's necessary.

Here, I want the following behavior from this code:

1. If any exception (including the corrupted state one) is thrown, then the lock should be unlocked, and the exception should be logged without reentrancy into this code region, if possible (LogLog allows such logging).
2. If the caller of this code uses [HandleProcessCorruptedStateExceptions], then let it to handle the exception as it wants to.
3. If the caller of this code doesn't use [HandleProcessCorruptedStateExceptions], then fall back to the default behavior (say, crash the whole process).

My point is that the logger internals shouldn't modify the defaults chosen by the application domain policy or by the caller. I don't think that this code should care about transforming corrupted state exceptions into ordinary ones.

[Friedrich von Never (ForNeVeR)]

After an internal discussion, we've decided to make this behavior configurable.