Consider auditing for Tenant deletion

[loneil]

When a tenant is fully deleted it's just all removed from the DB. For a in-use tenant that's a pretty "serious" operation so we can think about what auditing could be done to track if that happens, help with recovery if it's a mistake, and keep records for security incidents.

There would be existing log statements (at least just from the REST endpoint call) so there could be some tracking with Grafana as well?

But without relying on logging we could consider an Innkeeper audit table against the Innkeeper tenant that keeps track of these actions (as well as things like tenant creation, "make-issuer" allowance, etc)

As another feature on top of auditing we should probably have (at least for "normal" operational usage) emailing functionality when the delete is done through the Tenant UI (which is the only way real operators of Traction should be doing it anyways). Dispatch an email to the Innkeeper inbox about a deletion. Possibly can use the Tenant email on file to inform about deletion as well?
Consider if this should be done on suspension (soft-delete) too?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.