[12.x] Log: Allow scoping log context to a callback

[jsvdvis]

Description

This PR adds a Log::withScopedContext method that allows one to add log context that is scoped to that callback. After the callback is executed the extra log context is removed again.

// Any logs after this have the general context.
Log::withContext(['general' => 'context']);

Log::withScopedContext(['scoped => context'], function () {
    // Any logs here have both the general- and scoped context, scoped context is automatically removed afterwards.
});

// Any logs here have just the general context again.

Advantages

This mainly eases the use of #55181 (comment) and has similar advantages of using the callback with

Cache::lock()->get(function () {
    // Lock is automatically released afterwards.
});

Why

I frequently have code that executes separate tasks, e.g. custom jobs that do batches of work. There is a general context for the complete batch, plus a separate context for each unit of work. This means adding context before each unit of work and removing it afterwards.

I currently use Log::withContext(...) combined with Log::withoutContext(...) afterwards, as described in the PR above. However, this can be a hassle for two reasons:

• Whenever you add context at the start, you need to remember to remove it again at the end.
• You need to remember to correctly handle removing the extra context in your exception handling as well.

This current solution addresses both problems.

Potential other solution

I could also see this working as an extension to Log::withContext(...), by having the callback as a nullable second parameter. It would then function even more similar to how Cache::lock()->get(...) works. I mainly chose the current solution for clarity, but have no real preference.

Problems with the current solution

One unfortunate result of this solution is that it does not guarantee that the context at the end is the same as beforehand. This is primarily due to the array_merge usage in Log::withContext(...). This is fine for my use case, but it is something to take note of.

[jsvdvis]

Closing this, as this becomes difficult to reason with when e.g. using in a nested manner.