Store current storage usage and quota exceeding

[mbommerez]

This is a potential follow-up/enhancement for the account limiting feature. Currently, restricting accounts is done manually by admins based on the daily email alert that lists accounts which are over their quotas, but if we want to move to an automatic restriction system then we'll need to do this (or something like it).

In the Storage limits approach we discussed the following in Notion:

• Storing users and their current usage of storage on web3 (uploads & pins aggregated)
• Storing the percentage of allowance compared with their quota (stored in user_tags)
• Logging the date they exceed their allowed quota
• Removing that date once they go back under quota or their quota gets increased

This is important to deduce actions, such as automatic blocking once grace period is over etc. We can query the storage_usage table to get information on who is close to / already over their quota and perform actions accordingly (send emails, auto-blocking etc.).

Fields could be:

• user_id (from user)
• current_bytes_used (from user_used_storage function)
• current_percentage_of_quota_used
• quota_exceeded_at

Not storing a limit field, as that will just be fetched by: tag_value value from user_tag where tag = STORAGE_LIMIT.

[alexandrastoica]

Since we’re caching the storage used by a user id, should we:

1. initialise it to 0 when an account is created
2. update current_bytes_used whenever an upload or pin request is done
3. modify getUsedStorage to query the storage_usage table instead of calculating it every the time
4. change the FE (more specifically user/info endpoint) to get the total storage from the table instead of calc it

And also (although maybe a different ticket):

1. add a function to update quota_exceeded_at
2. calculate current percentage of quota used (better than storing it)

[adamalton]

There's a potential slight gotcha in this, which is that if the user's StorageLimitBytes account tag is updated, our current_percentage_of_quota_used (and possibly quota_exceeded_at) will become outdated. So there will need to be a mechanism for ensuring that when the former is updated, the latter (two) are also updated.

[mbommerez]

Parts of this could be applicable to the new proposed architecture for the storage limit email notifications. Ticket to be created. Moving this to the backlog for now.