initial implementation

[eli-darkly]

This implements a new package which I'm proposing we use in LaunchDarkly.ServerSdk, LaunchDarkly.CommonSdk, LaunchDarkly.XamarinSdk, and LaunchDarkly.EventSource, as a replacement for Common.Logging. The rationale is described in the Readme and also in our internal story (57336).

The intended usage is that application code will use a factory method/property (either from the Logs class, or from some other package for optional integrations) to obtain an implementation of ILogAdapter, which may include configuration such as minimum log level, and then provide that ILogAdapter to the SDK (or whatever other LD library is using this, such as EventSource).

    var sdkConfig = Configuration.Build("my-sdk-key")
        .Logging(Logs.ToConsole.Level(LogLevel.Warn))
        .Build();

Then, the SDK code will create named logger instances from that adapter and write messages to them. The logger name is an abstraction of a concept that exists in most logging frameworks; in the simple console implementation it's just written as a prefix to the message, but in frameworks like log4net it can be used for filtering. We'll use a dot-delimited namespacing convention in our logger names, for convenience with logging frameworks that can for instance apply a filter to "LdClient" but a more specific filter to "LdClient.Events".

    SomeSdkComponent(ILogAdapter logAdapter)
    {
        _logger = adapter.Logger("My.Logger.Name");
    }

    void DoSomething()
    {
        _logger.Info("A {0} thing happened", kindOfThing);
    }

So, when compared to our current usage of Common.Logging, the ILogAdapter is filling the same role as the static LoggerFactory methods; you obtain logger instances from it in basically the same way, except that 1. the ILogAdapter is an object that has to be passed into the SDK component, rather than being shared statically across the whole runtime, and 2. we always specify a name explicitly rather than using the "logger name is the same as the class name" shortcut.

I have some thoughts about how we should go about providing framework-specific log adapters; I've put those in a code-level PR comment because it's easier to follow conversations on those, as opposed to top-level PR comments.

This repo is currently private and will be made public once we're closer to a release.

[eli-darkly]

If this is approved, I'll still leave the repo private until we're closer to releasing the SDKs, but I'll publish an alpha version to Nuget so I can develop the other libraries against that.

[eli-darkly]

@bwoskow-ld

Minor question -- other repositories containing common SDK modules have been named in the -sdk- format. Should this repository be renamed to dotnet-sdk-logging?

I would say no, because this isn't only for the SDK. It's also used by dotnet-eventsource, which people can and do use outside of the SDK.