Be careful with logcontext in DeferredEvent

[MadLittleMods]

Be careful with logcontext in DeferredEvent

See docs/log_contexts.md#deferred-callbacks

synapse/docs/log_contexts.md

Lines 205 to 212 in 2fd8d88

	## Deferred callbacks
	When a deferred callback is called, it inherits the current logcontext. The deferred
	callback chain can resume a coroutine, which if following our logcontext rules, will
	restore its own logcontext, then run:
	- until it yields control back to the reactor, setting the sentinel logcontext
	- or until it finishes, restoring the logcontext it was started with (calling context)

---

Spawning from seeing the DeferredEvent usage in #19138

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)

[MadLittleMods]

This is the main fix!

See the Deferred callbacks section of our logcontext docs for more info (specifically using solution 2).

Heads-up, I wrote the docs too so it's my assumptions/understanding all the way down. Apply your own scrutiny.

[MadLittleMods]

This usage is actually probably fine given you can't get a handle to the raw deferred and add some callbacks to the chain that could cause the logcontext to change.

[MadLittleMods]

This was actually a problem, see #19146 (comment) for an explanation