Addition of User Object for user who initiated a ban in Ban Object

Currently the Ban Object only contains a User Object of the user who was banned and a String with the reason for the ban. It would be nice for bot devs to have access to the user who initiated the ban for more long term logging purposes, since items in the Audit Log (which do show who initiated the ban) expire relatively quickly.

The 3 month limit isn't the only limit. There's also a limit of 100 entries. For larger servers with significant automation (bots that remove messages frequently, users automatically getting kicked, etc.) 100 entries can be accumulated in a matter of an hour. That's easily fixed by occasionally requesting the audit log and storing it elsewhere, thus I don't think the 90 day/100 entry limit is an issue, and that's not what this suggestion is about.

Rather, this issue is about ease of associating user ban events received over websocket with the user who initiated the ban. Or alternatively, (and perhaps better), as I mentioned in my first comment, associating user ban events with audit log entries. When I mentioned that my suggestion would allow for better long term logs, that was only an example. Another example is notifying all moderators about the ban with a notification which includes information about the user who initiated the ban.

The 100 limit is new, which I was not aware of. Having the entry id in the GUILD_MEMBER_BAN event would be nice, but then we need to start talking about having the audit log entry id in all of the other actions that add entries to the audit log, which would be nice. I would love to just have the entry id, rather than having to scan the audit log for the action type, target id, and fetching the person who did it, and the audit log reason from there.

Another option would be for Discord to issue events each time an entry is added to the audit log. This would introduce redundancies in terms of user ban events, etc., but it would also add new events, such as invite creation, detection of which is currently only possible via polling the audit log once every 30 minutes and hoping that a single use invite wasn't created and used within those 30 minutes. In other words, it would help with tracking invite usage.