log: postpone log scrub to respond to write earlier

[xvuko]

This can improve relatively slow klog write times. It is still important to know that logging from threads with higher priority than usrv can result in priority inversion.

Description

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (list targets here).

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[agkaminski]

How is it blocked here? log_scrub only does proc_respond, it doesn't block in any way (except on a potential lock acquisition, but we need to get it anyway)

[xvuko]

How is it blocked here? log_scrub only does proc_respond, it doesn't block in any way (except on a potential lock acquisition, but we need to get it anyway)

It locks this lock second time and wakes up reader threads. If readers threads have same or higher priority than message handler than they could be scheduled before response is sent.

[agkaminski]

If read has higher priority it should be scheduled instead. I agree on the lock though, it should could be taken once for both operations instead.

How about moving scrub after common proc_respond instead? I don't like ad hoc look of the current version.