Improve attachments deletion

[lunny]

Refactor attachment deletion logic

The attachment of comment deletion process has been moved from the AfterDelete hook to the service layer. This change avoids scenarios where files are deleted while the database transaction is later rolled back. The new implementation introduces a two-stage deletion process via adding a new table named storage_path_deletion. All files need to be deleted will be added here and then a cron job will check it and delete the files. If file deletion fails repeatedly, a system notice will be issued to alert administrators.

This will also improve performance when deleting a release with many files.

Removed unused functions

DeleteAttachmentsByIssue and DeleteAttachmentsByComment are removed because only tests need them.

[wxiaoguang]

Overall doesn't look good .....

Change my opinion: it looks wrong.

[lunny]

Overall doesn't look good .....

Change my opinion: it looks wrong.

I’ve pushed some new commits. Could you please review them again and let me know if there are any concerns?

[wxiaoguang]

Overall doesn't look good .....

Change my opinion: it looks wrong.

I’ve pushed some new commits. Could you please review them again and let me know if there are any concerns?

The design is wrong and not worth to review.

If your plan is "the enum can be reused for other storages in the future", you need a separate table like "storage_file_deletion (storage_type, storage_path)", but not keep patching other tables.

[lunny]

@lafriks @wxiaoguang I reimplemented it and use a standalone table storage_path_deletion to handle file deletions. Please review again.