Reconsider FakeContext usage in infractions code

[wookie184]

I think we should consider (probably not in this PR) changing the type hints for any functions that can take a FakeContext, since just Context is misleading and makes it easy to introduce bugs like this.

I think the issue now is that we have 3 context classes: Context, FakeContext and FilterContext that are being used for conversion, and post_infraction takes either Context or FakeContext.

In this particular case, I think it's an instance of FilterContext that's being converted to FakeContext at the level of the InfractionAndNotification.action method .

But I do agree that it might need to be cleaned up.

I'll try to tackle this next.

Originally posted by @shtlrs in #2556 (comment)

[wookie184]

Places like this function https://github.com/shtlrs/bot/blob/6025015b471675de9f7eab9197899dd3eafcb4b0/bot/exts/moderation/infraction/_utils.py#L79 are currently type hinted as getting a Context, but they may instead get a FakeContext, which does not implement the full functionality of Context.

We should either update the type hints, or try and neaten stuff up another way that will help avoid bugs like #2555.

[mbaruh]

I'd like to note that for the linked issue, the bug would happen even if we could use Context. The bug happened because we tried to issue an infraction from a type of channel that was unaccounted for.

I'm ok with trying to clean this up. This was a hack I wrote because I didn't always have a Context to work with, such as in the case of on_voice_state_update. If you have a better idea I'm happy to discuss it, but the current solution is the least hacky thing I could come up with.