[feature] Implement Filter API v2

[VyrCossont]

Description

This pull request implements the Mastodon v2 filter API. v2 allows filters to be grouped and named, but the most important addition is the ability to filter individual statuses, which is not possible with v1. Want to hide an inflammatory, irrelevant, or unfunny post that your friends keep boosting? Now you can.

This is a follow-up to #2793, which implemented server-side filtering but only exposed it through the v1 API.

It also fixes several tests and minor bugs in the v1 filter API.

Impact

Phanpy only supports v2 filters, so this should make Phanpy more useful as a GtS frontend. (Tusky seems to be able to fall back to v1 if v2 isn't available, Feditext doesn't support v2 yet feditext/feditext#57, and Semaphore is EOL and only supports v1.)

Open questions

This version implements the keywords_attributes param for creating and updating filter keywords in the same API call as creating or updating a filter, and extends this to filter statuses with statuses_attributes parameters.

However, this functionality doesn't seem to be very well thought out. (More detail in https://princess.industries/@vyr/statuses/01HXDEFGK0W8R4M4X7TKB2RKNJ which is an unlisted post on a GtS instance so open that link in your Fedi client.) It duplicates separate calls for creating and updating filter keywords, I've had to make a lot of assumptions implementing it because it's based on a poorly documented Rails feature which doesn't map naturally to form parameters, and I haven't found a client that uses it to test against. Tusky actually has a comment suggesting that they avoided it on purpose:

This is terrible, but the all-in-one update filter api Just Doesn't Work

So maybe it'd be smarter to omit keywords_attributes and statuses_attributes, on the basis that they can't be incompatible with the Mastodon implementation if we don't ship them at all. However, I'd like to hear from client devs and make sure nobody is expecting to use them first.

Resolved: we're dropping these.

Checklist

• 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 not leveraged AI to create the proposed changes.
• 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]

Wow! Thanks for this PR :D

Re: those _attributes params, I'd be happy to just drop them from this PR and we can implement that functionality later if necessary (if there are clients that break without it).

[VyrCossont]

@tsmethurst sounds good. I'll remove that feature from this PR and we can resurrect it later if necessary.

[tsmethurst]

Great PR! I have only a few small comments and questions about error handling + return values. Once those are resolved this can be squerged imo. Excellent work, thank you for this :)

[tsmethurst]

Great stuff!