Improve notifications to fix commit notification and support release notification

[lunny]

This PR improved notifications.

• Improve repository transfer notification to use the queue rather than directly insert database records

• Fix commit notification which never work before
• Add release notification, inspired by Show Release Notification in the UI #27058 and will replace it.

[wxiaoguang]

Are these indices well-designed and correct?

You can't just add index to every column and expect that "oh it should work".

Does database work really work that way?

[lunny]

This highlights a significant design flaw in the current table structure.

In this PR, we introduced a new column, release_id, to support release-type notifications.

[wxiaoguang]

The database design looks strange.

If I understand correctly, what you need is "a unique key to avoid duplication and help to mark the notification as read". I think it could be resolved by a more flexible approach like:

unique_key = 'commit-{CommitID}'
unique_key = 'release-{ReleaseID}'
unique_key = 'comment-{IssueID}-{CommentID}'

Then we only need one unique index (user_id, unique_key)

---

And, some legacy indices like status, source seem not able to help to improve querying performance because if user_id is used, then these indices won't be used.

---

And, the user_id index is redundancy because there is already (user_id, status, updated_unix). If you would take more care about performance, these problems should be handled.

[lunny]

The source should also be part of the unique key. Currently, issue and release notifications require a unique key, while commit and repository notifications do not.

[lunny]

Maybe we should use a one column to store this id, otherwise the unique key seems too complicated.