Think through "audit" logging

[slifty]

We have recently started creating the ability to update and delete things in our system; prior to this, all meaningful actions via the API were naturally "logged" in that they would result in a new row in a table somewhere. That's no longer true in the case of things like editing a base field or deleting a permission.

To that end we need to think about how to keep track of that information.

There was talk of an audit log; there was also some talk about trying to have tables that are individually designed to inherently maintain all activity. This issue description is not intended to prescribe a given design direction, but rather the point is to pick that direction.

[bickelj]

I think we should use triggers on tables to create entries in an audit log table. Something like audit trigger but with the additional context of the application-level user (Keycloak Subject ID) included. Log files (such as employed by https://github.com/pgaudit/pgaudit) are not sufficient because they are outside the database and we have a limitation on logging due to our issue #1266. I think the "log files are outside the database" is enough reason to avoid them, though, because we need the audit trail accessible in-band such that a future administrative interface can view the audit trail. This raises the spectre of audit logging the views of the audit trail. No, we should not create an infinite loop. I expect to only audit data modifications at first, and if we audit views, we will be tracking only the proposal/business data rather than the audit data.

[slifty]

We've thought through it! Hooray! (#1559 has more thoughts, and we reserve the right to think in the future as well.)