[Audit log] Track authentication events separately from AuditEvents

Problem to solve

Login events are currently being captured as AuditEvents. There are some problems with this approach:

1. Performance: Login events account for a large proportion of total AuditEvents; over 40% of AuditEvent volume on gitlab.com. They contribute substantially to performance issues with AuditEvent.
2. Technical debt: Login events are substantially different from a typical AuditEvent, because they do not capture a change. This is clear if you look at the categorization of AuditEvents - for typical AuditEvents the actions are create/update/delete. For login events the actions are things like "standard" and "Google", which aren't actions but types. No change has occurred, instead the user has simply passed (or not passed) through a gateway. So at least from the technical perspective, login events do not nicely fit the AuditEvent classification.
3. (Tentative; is this true?) UX: Customers prefer to see login events separately, in a security dashboard, rather than interspersed in the change dashboard (the audit log).

Proposal

Authentication events (failed and successful logins) should be displayed in a separate tab in Audit Log.

In the future this tab could be enhanced to display specific users or IP addresses and look for suspicious patterns.

Related links

• This issue fits in the theme of developing a stronger opinion about the nature of AuditEvents, which is related to our wide-ranging AuditEvent refactor.
• Users already have an "Authentication log" that shows a "History of authentications" for their account (see /-/profile/audit_log).