API active blocks list

[AntonKhorev]

See https://community.openstreetmap.org/t/is-this-the-same-person/123461/30

Problem: how an app accessing OSM API can determine that the current user is blocked, and tell them that they're blocked? Here's a method I came up with: streetcomplete/StreetComplete#6062 (comment). It has two hacky steps:

1. accessing /api/0.6/user/#id without auth header, because /api/0.6/user/details is inaccessible while blocked
2. generating a login link with referrer pointing to the block list

Some people access an endpoint that is known to generate 403 errors only when blocked instead of 1, but there's no guarantee that things will stay that way. /api/0.6/user/#id may also become inaccessible without authorization in the future. This PR does 1 in an unambiguous way by providing an endpoint that lists active blocks for the current user. It it accessible even if the user is blocked.

GET user/blocks/active outputs a list of <user_block> elements like #4240. Currently I'm skipping block reason texts because I'm making this similar to Messages API which also skips message texts in lists. While this list is short and adding reasons wouldn't make the results very long, we may add a similar list of all blocks / by all users and it will get long.

I probably should add a limit but I can't imagine anyone collecting a lot of active blocks. More than one is already unusual.

user/blocks/active requires read_prefs scope, which may look strange, but that's because this scope is also responsible for user identity. Similarly user/details requires read_prefs despite not reading preferences.

[tomhughes]

I don't understand why we don't just make the user details call work even when you're blocked - in fact all read calls I would have thought should work.

That's not to say we might not want this as well as the details call only gives a count of blocks and not the details though I guess we could add that as an alternative to this.

[AntonKhorev]

If I remember correctly, at some point DWG discussed making user/details accessible for blocked users and concluded that sometimes we want it blocked. It's similar to changeset comments: in most of the cases we want blocked users being able to post comments but sometimes we don't.

We'd need different types of blocks. I'm thinking about blocks that would have scopes like auth tokens. Abilities would be checked against (scopes granted by the token) - (scopes removed by active blocks).