Satellite self-serve account deletion

[cam-a]

https://github.com/storj/storj/issues/6911

We want to allow users to delete their accounts from the web UI. To accomplish this we will add two new columns to the users table: status_updated_at and final_invoice_generated. status_updated_at is a timestamp column containing the time at which the status column was updated. Can be nullable for backwards compatibility. final_invoice_generated is a boolean column indicating whether the user's final invoice has been generated after they have requested account deletion and are a PRO user. This is to make sure we don't delete PRO users before their final invoice is created because we still want to bill them.

There is already a user status, pending_deletion, which is set for users who do not pay their invoices, but currently we don't delete these users based on this status. We could also use this for users who have opted for deletion, or we could create a new status to specifically identify users who have opted for deletion. We would like to be able to identify users who have opted for deletion, so we could use a different status for this, or logs, or analytics. A different status would also allow us to handle different "deletion" statuses in different ways if we wanted. If a new status is created, the name of the pending_deletion status should be changed because it would then be too broad. However, in the end, once the user is deleted, the status is set to deleted.

The user will make some action on the frontend which will make a request to a new endpoint that updates the user status to something identifying them for deletion, sets status_updated_at, sets all rate and burst limits to zero, deletes all API keys and sessions, and sends an email to the user confirming the deletion request. pending_deletion users should not be able to log in or take any actions. There may also be some emails to implement (e.g. an email code to input to authorize the deletion request, etc.) See the flow at https://github.com/storj/vuetify-storj

During the invoice generation process, check if the user is pending_deletion and if status_updated_at exists within the billing period of invoicing. If so, set the upper limit on the billing period to status_updated_at, so they aren't billed for stored data since the time they opted for deletion. Once the invoice is finalized, set final_invoice_generated to true. Free users don't get invoices, so this is irrelevant for them.

Create an admin endpoint to return a CSV of all users who are ready for deletion:

select email from users 
where status = pending_deletion 
and (paid_tier = false or final_invoice_generated = true)

We could also perhaps add a timestamp field, pendingDeleteBefore, to the request to only get users where the pending_deletion time is before this value. This would give us the ability to restrict the deletion to users who have been in the state for a certain amount of time.

The deletion script here takes a CSV of users to delete, but requires projects to be empty before deletion. This means we will need to make changes to the delete project endpoint to allow for the deletion of non-empty buckets. In the delete project endpoint logic, if the user is pending_deletion and (paid_tier = false or final_invoice_generated = true), we can delete buckets that still contain objects. Otherwise, we should not delete buckets.

### Tasks
- [ ] https://github.com/storj/storj/issues/6966
- [ ] https://github.com/storj/storj/issues/6968
- [ ] https://github.com/storj/storj/issues/7002
- [ ] https://github.com/storj/storj/issues/7003

[wilfred-asomanii]

pending_deletion users should not be able to log in or take any actions. During the invoice generation process, check if the user is pending_deletion

Earlier in the doc, it was not decided whether a new status name should be used. So are the use of pending_deletion here placeholders?

[cam-a]

pending_deletion users should not be able to log in or take any actions. During the invoice generation process, check if the user is pending_deletion

Earlier in the doc, it was not decided whether a new status name should be used. So are the use of pending_deletion here placeholders?

Yeah, it just means whatever status we decide to use for these users

[storj-gerrit[bot]]

Change satellite/payments: update invoicing logic to handle accounts marked for deletion mentions this issue.

[storj-gerrit[bot]]

Change satellite/{console, web}: remove feature flag for object browser pagination mentions this issue.