General way of handling incompatible Mastodon API changes?

[bocops]

Mastodon's API is under development and thus changing between releases. Relevant changes are marked by increasing an int value that we can now access in our built client and its individual methods as client.getInstance().apiVersions.mastodon.

In #557, we first stumbled upon an API change where interpreting this value might become necessary. API version 5 adds a new "filter action" (an action that a client should perform when displaying posts matching a filter). We need to add this action to our Filter.FilterAction enum, so that library consumers are able to correctly retrieve this value where set for a filter (e.g. FilterMethods.viewFilter(id)). However, by adding it to the enum, we make this new action available for creating new filters as well (FilterMethods.createFilter(..., filterAction)) - including on instances running API version <5, where the request will fail because the action is unknown and considered to be invalid.

In this case, we need to prevent this action to be sent to certain Mastodon servers completely, potentially at the cost of failing the request with an exception. At other times, we might get away with changing or just ignoring individual parameters so that the request can succeed. I believe we need to discuss and define how we want to handle these cases generally, considering that we're not just creating a self-contained client but a library that others might want to use for potentially very different use cases. What further complicates this is the fact that these are basically run-time issues, depending on the specific Mastodon instance being used. The core question is:

if (filterAction == Filter.FilterAction.BLUR && client.getInstance().apiVersions.mastodon < 5) {
    // The surrounding request will fail - generally, could be HTTP 50x, could be HTTP 4xx, could just do nothing of value.
    // TODO: What do we want to do about it?
}

Option A: Do Nothing
Basically, let the library consumer beware. If they don't want to send invalid requests, they should check Mastodon's API themselves. If they are OK with it, an exception will be thrown that they need to catch and handle. Problems: unnecessary requests being sent, not very helpful for a library.

Option B: Check and throw
Just throw an exception that the consumer needs to catch and potentially repeat the request with different data. Problem: better than A in terms of resource usage, but otherwise no difference from the consumer's perspective, resulting in overhead on the consumer's side for potentially problematic requests.

Option C: Massage input data
Try to fall back to other values (in the example case, send FilterAction.WARN instead of .BLUR). Problems: we're defining one "true way" that some library consumer might not agree with, but might also not even be aware of, leading to inconsistencies.

Option D: Validity checks for requests
Offer functionality that checks whether a specific request (combination of parameters and built client) can be successfully performed in theory, without already performing it. Problems: overhead on our side, overhead on the consumer's side; how?

Option E: Client parameter to toggle behaviour
In MastodonClient.Builder, offer a setting that allows the resulting client to behave in different ways, for example a "strict" mode that always fails with an exception vs. a "lenient" mode that changes inputs for the request to succeed, at least to some extent.