Use the standard LoggerFactory with the ConsoleLoggerProvider

[sgryphon]

I've done a lot of work with diagnostics, and the new .NET Core logging was being used in a slightly non-standard way (it could have been based on early versions/code).

Rather than implement your own ILoggerFactory that creates loggers directly, and your own null logger, generally you use the framework LoggerFactory and configure it with the ILoggerProvider(s) that you want.

If there was/is some grand plan to do your own stuff, then feel free to ignore this; otherwise, this pull request ends up with the same result (a basic console logger) with much less code (removed the two custom classes).

This change:

• Uses the standard LoggerFactory with the ConsoleLoggerProvider, rather than manually creating loggers. (There is a utility method AddConsole() that does this for you)
• Remove the custom FuncLoggerFactory.
• Note the default will already create null loggers (if you have no providers), so that isn't needed either; removed the custom NullLogger.
• Change the first parameter of the config of the console logger from a func(n,l) => true, to just specify the lowest min level, which is a bit simpler.

[dangershony]

I don't know of any grand plan Nicolas had, however we need to implement logging based on categories.
Specified in the config file will be: "debug=net,db,trx" etc...
From the code it seems the console logger just filters out by trace type ,any suggesting on enhancing the console logger to also filter by categories, or a custom implementation?

[sgryphon]

Yes, I've done heaps on diagnostics, so relatively easy to configure by type (including via a configuration file). This current pull request however doesn't change functionality -- it does the same as the current code, just using existing framework classes rather than creating custom ones.

[dangershony]

Gotcha, looks good.

[sgryphon]

Some basics:

• First of all, each category (ILogger) can have the logging level set; this includes a Default level, system loggers (System, Microsoft), and each of your own loggers.

• You can also create a hierarchy of loggers, and configure at any level, e.g. "Default" cascades to everything unless overridden, "System" cascades to all System, etc.

• e.g. You could have loggers like Stratis.Bitcoin.Consensus and then Stratis.Bitcoin.Consensus.CoinViews will inherit.

• The usual pattern is to use namespace/class names, and these are generated automatically by CreateLogger'T(). Even when you have 10 classes, with 10 loggers, you only need to configure once at the higher level (as they inherit).

Normally the logging is configured via logger=level, but I can add a converter that allows compatibility with core bitcoind parameters (i.e. debug=cat1,cat2,cat3). I will write it up and do another pull request (branched from this one).

[dangershony]

Awesome that would be really great, I guess the categories should coincide with any of the ILoggers in Log.cs (debug=bench,rpc,fullnode, etc), even if its not exactly similar categories to core we can fix this up later if we see fit.