[feature] PATCH /api/v1/admin/custom_emojis/{id} endpoint

[tsmethurst]

The new PATCH endpoint allows instance admins to:

1. copy a remote emoji to local storage.
2. modify a local emoji with a new image, shortcode, and/or category.
3. disable a remote emoji, preventing it from being used on the instance.

finishes / closes #797
finishes / closes #821

[tsmethurst]

There's two things I'm still uncertain about:

1. Allowing shortcodes to be changed, since this might break things in some spicy way -- should we make admins delete + recreate emojis instead to change the shortcode?
2. When a remote emoji is disabled, should we also delete all references to the emoji in the status_to_emoji and account_to_emoji tables? This will make it more difficult to reenable the emoji, should admins want to do that (and should we actually implement reenabling disabled emojis in future).

[f0x52]

1. Allowing shortcodes to be changed, since this might break things in some spicy way -- should we make admins delete + recreate emojis instead to change the shortcode?

Can we do that automatically? PATCH shortcode change > return updated emoji with a new ID too

2. When a remote emoji is disabled, should we also delete all references to the emoji in the status_to_emoji and account_to_emoji tables? This will make it more difficult to reenable the emoji, should admins want to do that (and should we actually implement reenabling disabled emojis in future).

What makes this harder to re-enable?

[tsmethurst]

What makes this harder to re-enable?

basically it means we gotta go through and recreate all the links we deleted, in order for the disabled+re-enabled emojis to once again be returned properly attached to statuses via the api

Can we do that automatically? PATCH shortcode change > return updated emoji with a new ID too

mmmmm maybe 🤔 i can play around with that

I think this will always be a bit difficult though. Say you've got a status like hello :blob:, where blob is an emoji with id 1. Then someone changes the shortcode of the emoji 1 to :yell:. Now when you select the status from the database, it will still come with emoji 1 attached to it, but because the shortcode is now yell instead of blob, the text in the status won't be replaced properly with the emoji icon. If that makes sense. I need more :coffee:.

So this situation isn't actually mitigated by deleting and replacing the emoji so that it has id 2 now, because the text in the original status will still include :blob:.

[NyaaaWhatsUpDoc]

Is this ready to review @tsmethurst ? Just judging based on that last reply ^. Though to go back to your previous comment, I think making admins delete->recreate would be my preferred method of handling emoji shortcode changes. It saves us having to deal with odd situations on the backend, and it makes it more clear that if you rename an emoji shortcode that existing statuses will have broken shortcodes. Going back and updating them all is definitely out of the question IMO, as it would either mean having to send out a tonne of AP update events to keep remote copies in line with ours, or remote copies just wouldn't be inline with our local status copy (which also doesn't seem great)

[tsmethurst]

Alrighty, I removed the ability to update shortcodes cuz yeah, it's gonna cause nothing but headaches 😬 So this is ready to review! :)

The only thing still missing, i'd say, is going back through statuses and updating the emojiIDs on them when an emoji is deleted. But this is not a big deal for now I think, since the serialization stuff will just skip over the emoji if there's an error getting it: https://github.com/superseriousbusiness/gotosocial/blob/main/internal/typeutils/internaltofrontend.go#L607

[NyaaaWhatsUpDoc]

Alrighty, I removed the ability to update shortcodes cuz yeah, it's gonna cause nothing but headaches grimacing So this is ready to review! :)

The only thing still missing, i'd say, is going back through statuses and updating the emojiIDs on them when an emoji is deleted. But this is not a big deal for now I think, since the serialization stuff will just skip over the emoji if there's an error getting it: https://github.com/superseriousbusiness/gotosocial/blob/main/internal/typeutils/internaltofrontend.go#L607

I'm going to merge this now, but do you want to make a ticket for this remaining task at some point ^