chore: route connection logs to new table

[ethanndickson]

This is the first PR of a few for moving connection events out of the audit log, and into a new database table and web UI page called the 'Connection Log'.

This PR:

• Creates the new table
• Adds and tests queries for inserting and reading, including reading with an RBAC filter.
• Implements the corresponding RBAC changes, such that anyone who can view the audit log can read from the table
• Implements, under the enterprise package, a ConnectionLogger abstraction to replace the Auditor abstraction for these logs. (No-op'd in AGPL, like the Auditor)
• Routes SSH connection and Workspace App events into the new ConnectionLogger
• Updates all existing tests to check the values of the ConnectionLogger instead of the Auditor.

Future PRs:

• Add filtering to the query
• Add an enterprise endpoint to query the new table
• Write a query to move N entries from the audit logs table to the connection logs table, call it from dbpurge.
• Implement a table in the Web UI for viewing connection logs.

Note

The PRs in this stack obviously won't be (completely) atomic. Whilst they'll each pass CI, the stack is designed to be merged all at once. I'm splitting them up for the sake of those reviewing, and so changes can be reviewed as early as possible. Despite this, it's really hard to make this PR any smaller than it already is. I'll be keeping it in draft until it's actually ready to merge.

[ethanndickson]

• chore: route connection logs to new table #18340 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[ethanndickson]

Requesting a draft review just to confirm we're happy with the DB schema, the RBAC setup, and the overall direction.

[mafredri]

Nice work! I think this looks great in general, but the upsert part of the logic here doesn't fully make sense to me (see related comment). Could you elaborate on the intent?

[mafredri]

Suggestion: This feels more like a "fake" than a "mock".

[mafredri]

Suggested change

	LEFT JOIN users as workspace_owner ON
	LEFT JOIN users AS workspace_owner ON

[mafredri]

Note: Using limit/offset will get increasingly more slow as the table grows and you paginate further. First page will usually remain fast though.

Fine for now, though. Just raising awareness.

[mafredri]

Considering we have both connect and disconnect enums and type is not part of this conflict handling, it suggests to me there is some gap in the logic. Considering connect/disconnect both share the same connection ID, we'll never write the disconnect but upsert the connect with close time and reason.

Either writing two entries, or doing a upsert, might make sense. But I think we have to ask what are we trying to achieve here and how are we looking to display the data?

My take as a user would be that I want to see two separate entries in the log, appearing in their chronological order. When viewing the connect, it would be an additional nice bonus to be able to see when the disconnect happened, and vice-versa that could simply be achieved by applying the connection ID as search filter.

EDIT: Correction, I was referring to "connection_action" (connect/disconnect), not "connection_type". But upon closer inspection that database type is not even used so it should probably be removed if not intended to be used.

That said, I want to clarify that I'm not concerned with whether or not we write two entries or upsert one, but in the latter case I do think we should make sure to "explode" the data when queried so that we can show the events in their chronological order.

[ethanndickson]

EDIT: Correction, I was referring to "connection_action" (connect/disconnect), not "connection_type". But upon closer inspection that database type is not even used so it should probably be removed if not intended to be used.

Part of the reason for connection_action is to better differentiate connection_logs when they're output to the coder server logs (the slog backend for the connection logger). Without including it on the InsertParams, for a connect + disconnect, you'd just see two logs, one with close_time set, one without. The other reason is to ensure we don't incorrectly mark a connection as closed if an agent erroneously sent multiple connect events with the same connection ID. I do agree to see it's weird to see a database type only used in a query and not in the database, but this seemed like the most appropriate way to handle both these cases.

I do think we should make sure to "explode" the data when queried so that we can show the events in their chronological order.

This is a good point. In my head I envisaged the final UI just including a duration on the table, the idea being that the connection events were more important to the end user. Based off what I've heard of how users request / use this existing connection log data, I didn't think we'd be breaking any existing usecases by not showing disconnections intertwined with connections. Whilst I think we can explode the data in the query (and show connections and disconnection events chronologically), I'm not sure it'll play nice with pagination; i.e. you ask for offset 25, but instead of starting at the 26th disconnection or connection, your page starts after the most recent 25 connections.