Revamp the logging generator to use the new redaction model.

[geeknoid]

• This new code leverages LoggerMessageState to take advantage of the new ExtendedLogger design.

• The tests were updated for three reasons:

  • Stopped using IRedactorProvider in here, this is handled by
    the ExtendedLogger

  • Fixed brittle test logic assuming the order of the name/value pairs
    produced by the logging code generator. The tests are now order-
    independent.

Microsoft Reviewers: Open in CodeFlow

[xakep139]

Stopped using LogLevel.Debug since it ends up getting filtered
away by default, and switching the default is a pain.

Why is that? You can add builder.SetMinimumLevel(LogLevel.Trace) in Utils.GetLogger()

[xakep139]

As @klauco pointed, we should still support this use-case. Maybe not in 3P though 🤔

[geeknoid]

Removing redactor provider support was a huge simplification. I'd really need to be convinced that supporting it is a useful thing within the redaction infra.

Note that there's nothing preventing the customer from grabbing an IRedactorProvider themselves and redacting stuff on their own before calling the lower-level log method.

[klauco]

can we provide analyzer and fixer for existing customers, to move to the signature which does not use IRedactorProvider?

[geeknoid]

Stopped using LogLevel.Debug since it ends up getting filtered
away by default, and switching the default is a pain.

Why is that? You can add builder.SetMinimumLevel(LogLevel.Trace) in Utils.GetLogger()

Oh, let me try that. I was trying to figure out how to change the default minimum level and just didn't land on a solution.