[feature] Push status edit messages into open streams

[Sentynel]

Description

When a status update message comes in (i.e. a status is edited), push the appropriate status.update message to any connected streams that would have received the original status.

Slightly WIP still but does work.

closes #2417

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.

[tsmethurst]

Nice one; I think we will save this for after 0.13.0 so we can try it out on main and tweak it as necessary :)

[Sentynel]

Yep, wasn't expecting this to make it into this release - I've tested that it sends messages that look like the Mastodon ones, but I haven't tested it with different clients or anything.

Outstanding questions I think are:

1. I've basically duplicated a chunk of the new status -> timeline processing code in surfacetimeline.go for the update route instead, but maybe it's better to add an "edit" parameter to the existing code and alter the flow as appropriate instead? It's basically the same code but without the actual inserts and the notification generation, which could be stuck behind an "is_new_status" guard instead. Slight reduction of copy-and-paste code, slightly harder to follow the logic.
2. Speaking of notifications, I'm not notifying on edited statuses. This feels like the right move in general, but does mean that if somebody edits a mention into a post we don't notify. I think that's a reasonable trade-off? I can't think of a clean way of working out if a mention is new in the edited version in order to generate a new notification (you'd have to add a bunch of accounting to keep track of the notifications you've sent for each status, which sucks, or diff the edit history, which sucks less but still sounds annoying).

[NyaaaWhatsUpDoc]

Yep, wasn't expecting this to make it into this release - I've tested that it sends messages that look like the Mastodon ones, but I haven't tested it with different clients or anything.

Outstanding questions I think are:

1. I've basically duplicated a chunk of the new status -> timeline processing code in surfacetimeline.go for the update route instead, but maybe it's better to add an "edit" parameter to the existing code and alter the flow as appropriate instead? It's basically the same code but without the actual inserts and the notification generation, which could be stuck behind an "is_new_status" guard instead. Slight reduction of copy-and-paste code, slightly harder to follow the logic.

2. Speaking of notifications, I'm not notifying on edited statuses. This feels like the right move in general, but does mean that if somebody edits a mention into a post we don't notify. I think that's a reasonable trade-off? I can't think of a clean way of working out if a mention is new in the edited version in order to generate a new notification (you'd have to add a bunch of accounting to keep track of the notifications you've sent for each status, which sucks, or diff the edit history, which sucks less but still sounds annoying).

great work here! nice one :). regarding 1) honestly i quite like how it is currently, as you say making a singular function share logic for both makes it a bit more complicated now, and in the future if there's further diversion it could start to get a bit hairy :P. and for 2), as you say that's a bit of an awkward situation adding in a mention to an edited post, i think that's something we can safely leave for now as it's a bit of a niche situation. also, if anyone further replies after that the person will still get notified for any new mentions of themselves. we can probably save that functionality until we actually support full edited statuses logic including revision history.

for the code in the PR itself, i don't actually have any comments on it myself! looks great. for bonus points if you feel up to it a test to trigger an update notification (which you'd need to add in ./internal/processing/stream/notification_test.go) would be useful, but not a blocker for squash+merge.

[NyaaaWhatsUpDoc]

only one comment on the added test, otherwise looks all good to me @Sentynel 👌

[tsmethurst]

Thank you!