Delegate ScopedContext functionality to interface

[ppkarwasz]

To provide more configurability for the ScopedContext service, this PR moves its implementation details to log4j-core and replaces it with a ScopedContextProvider interface.

In Log4j API only a NO-OP version of the provider is present, but each implementation of the API can provide its own.

[rgoers]

I took a look at this again. I missed some things the first time through it. I like most of this but will want to change it a bit.

[ppkarwasz]

I took a look at this again. I missed some things the first time through it. I like most of this but will want to change it a bit.

Feel free to directly modify this branch.

[rgoers]

Rats. I didn't mean to but I merged my changes to this branch by mistake. They are now in the ScopedContext branch as well.
Oh - I just notice you said it was OK to modify this branch.

I have a question though. I just noticed that you made the default ThreadContext provider a no-op. How did that manage to pass unit tests? Why does it need to be a no-op. For one, SimpleLogger includes the MDC in the output so I would think anyone using it would expect it to work.

[ppkarwasz]

I have a question though. I just noticed that you made the default ThreadContext provider a no-op. How did that manage to pass unit tests? Why does it need to be a no-op. For one, SimpleLogger includes the MDC in the output so I would think anyone using it would expect it to work.

I removed ScopedContext from SimpleLogger: IMHO it isn't a simple logger any more if it contains complex data.

Since I was mostly concerned with ScopedContext, I disabled the ResourceLoggerTest temporarily (shouldn't ResourceLogger be in another PR anyway?). I moved the ScopedContextTest to log4j-core, since this is where a non-trivial implementation resides. In log4j-api-test I left an abstract class that should be used to test all the implementations of ScopedContextProvider.

[rgoers]

I disagree with your premise. SimpleLogger has always supported logging the ThreadContext. Including the ScopedContext as well makes sense since they can be interchangeably used. You adding a Noop implementation of ThreadContext essentially breaks backward compatibility. We need a minimal implementation in the API.