[feature] Status thread mute/unmute functionality

[tsmethurst]

Description

If this is a code change, please include a summary of what you've coded, and link to the issue(s) it closes/implements.

If this is a documentation change, please briefly describe what you've changed and why.

This pull request implements support for muting/unmuting a status thread in order to ignore notifications on that thread for replies, boosts, and likes. Useful when you've posted a banger and the notifications on it become overwhelming, or when you've been mentioned in a thread you're not interested in.

To enable this functionality, the concept of a 'ThreadID' has been added to the codebase:

What's a ThreadID

Not much, what's a ThreadID with you?

Local statuses are now assigned a thread ID when they're created, and subsequent replies to that status, and any children of that status, inherit the thread ID of their parent. This includes replies made by both local and remote accounts. This provides an easy, good-enough way of recognizing whether a status is part of a thread, without having to navigate up a whole chain of statuses looking for a relevant parent.

New remote statuses (either top-level or replies) either inherit the threadID of their parent, or get a new threadID created for them if they mention a local account. If they don't mention or reply to a local status, they don't get a threadID since there's no point keeping track of that.

DB functions have been added to select the IDs of all statuses in a thread. Although these aren't currently used for anything, they might come in handy in the future. Related: this PR doesn't replace (or intend to replace) the existing logic for modeling a status's context by looking up and down through ancestors and descendants. Maybe we could use thread IDs like that in the future, but I don't think so and it's not of interest right now since our existing system works rather well.

How do mutes work

When you mute a "status" you're actually creating a mute that targets the thread ID of that status. When a notification is about to be generated for a reply/like/boost, the notification function will first check if there's a mute in place of the thread to which the notification-creating activity belongs. Only if there's no mute will the notification be created.

Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: [ ] -> [x]

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[iliana]

(Apologies for a drive-by question — I'm looking at a few different ActivityPub implementations to see what might meet my needs in the near future. Thanks for your consideration!)

If I'm reading the PR description properly: each status can only belong to a single ThreadID, correct? A feature I would find helpful is the ability to mute a subthread, for situations where some people decide to have a conversation in my replies that I no longer wish to observe, but still see notifications for the rest of the thread.

Being able to keep track of multiple ThreadIDs would be useful for that, but I'm not sure how that would look in either the database or the API.

[tsmethurst]

If I'm reading the PR description properly: each status can only belong to a single ThreadID, correct

That's right yes!

A feature I would find helpful is the ability to mute a subthread, for situations where some people decide to have a conversation in my replies that I no longer wish to observe, but still see notifications for the rest of the thread.

That makes sense. Unfortunately it's a bit of a pain in the arse because every reply can technically be a subthread, so in deeply nested threads with lots of replies you're gonna end up keeping track of a bananas amount of thread IDs.

Not something to be fixed for this PR, I think, but perhaps in future we can fiddle with this and see if there's a way to mute from a specific status ID downwards, instead of muting a thread ID. Not sure though!

Apologies for a drive-by question

No worries :)

[NyaaaWhatsUpDoc]

A few points worth addressing, but otherwise this looks great :D