OSOE-402: Custom logging instead of NLog-based one

[Piedone]

OSOE-402
Fixes #206

To be added to the release notes on the next release:

Breaking changes in logging during UI tests

One of the implicit assertions that the UI Testing Toolbox does automatically is checking the Orchard Core application logs for any errors. By default, any error fails the test.

Previously, this relied on the tested web app using NLog for logging, and it parsed NLog log files. This not only required the app to use NLog over Serilog (that Orchard also supports out of the box) or any other logging framework, but it also depended on the structure of an otherwise freely configurable textual log format.

Now, the UI Testing Toolbox configured the app to use FakeLogger in addition to any logging framework it has set up, and uses it for assertions. FakeLogger not only doesn't need anything specific in the app, but it also lets you access and assert on log entries in a structured, statically typed way.

Using NLog is still

What changed

• All log management methods are now async.
• Log assertions now don't happen on a string representing the whole log, but rather on IApplicationLog and IApplicationLogEntry instances.
• The LogsShouldBeEmptyAsync and GetLogOutputAsync methods are changed, see the diff.
• CreateAppLogAssertionForSecurityScan and CreateAppLogAssertionForSecurityScan work the same but were moved into the Lombiq.Tests.UI.SecurityScanning namespace.
• A new OrchardCoreConfiguration.AfterFakeLoggingConfiguration event handler is exposed to change the default configuration of FakeLogger.
• OrchardCoreUITestExecutorConfiguration.AssertAppLogsCanContainWarningsAsync and OrchardCoreUITestExecutorConfiguration.AssertAppLogsCanContainWarningsAndCacheFolderErrorsAsync are no longer available.

How to adapt

• Use OrchardCoreUITestExecutorConfiguration.AssertAppLogsCanContainCacheFolderErrorsAsync instead of OrchardCoreUITestExecutorConfiguration.AssertAppLogsCanContainWarningsAndCacheFolderErrorsAsync .
• OrchardCoreUITestExecutorConfiguration.AssertAppLogsCanContainWarningsAsync is not needed, since the new behavior is to not log warnings in the first place.
• The examples are updated in Lombiq.Tests.UI.Samples.UITestBase, see the diff. Check them out if you have custom app log assertion code.

[dministro]

This approach may change the order of the log records. I would be surprised if we will have more than a few hundred log records here. Do we need parallelization?

[dministro]

This can be a record.

public record FakeLoggerApplicationLogEntry(FakeLogRecord LogRecord) : IApplicationLogEntry
{
    public LogLevel Level => LogRecord.Level;
    public EventId Id => LogRecord.Id;
    public Exception Exception => LogRecord.Exception;
    public string Message => LogRecord.Message;
    public string Category => LogRecord.Category;
    public DateTimeOffset Timestamp => LogRecord.Timestamp;

    public override string ToString() => FormatLogRecord(LogRecord);

    public static string FormatLogRecord(FakeLogRecord record) =>
        StringHelper.CreateInvariant($"{record.Timestamp:yyyy-MM-dd HH:mm:ss.fff} [{record.Level}] {record.Category}: {record.Message}") +
        (record.Exception != null ? record.Exception.ToString() : string.Empty);
}

[dministro]

Note to myself: This was a question mark, but the instance is resumed in TakeSnapshotInnerAsync.