API: Joins / Relations refactor

[ErisDS]

This issue is a little bit of a mixed bag, I needed to brain dump all of the small join / relation related tasks that need to be done to ensure we get consistent behaviour across the API.

Joins / Relation handling

• Move all the handling of joins / relations into one place:
  • Posts: tags, author
  • Tags: posts
  • Users: posts, roles
• Make it possible to use joins in fields

Count handling

• Change post_count include on Tag endpoint to be posts.count
• Add tags.count to Posts endpoint and posts.count to Users endpoint

Perms & Cleanup

• Once public endpoint perms are in place properly (API: Public endpoint permission handling (public access rules) #5614) ensure that the inclusion of Posts adheres to the same policy
• Once public endpoint perms are in place properly (API: Public endpoint permission handling (public access rules) #5614) ensure that the inclusion of counts adheres to the same policy
• Overhaul next & previous post implementation so that it is possible to include next.tags and next.author etc (fix Bug: {{author}} & {{tags}} not showing up when using {{#prev_post}} or {{#next_post}}  #5150)
• Once the filter parameter is in place (API: Filter parameter (GQL filter queries spec) #5604), get rid of the tag & author parameters for posts, and the role parameters for users.

Provide access to more joins / relations:

• Users by role

Maybe:

• Allow for include of Posts from Tag or User endpoints
• Consider adding support for relations between users and tags through posts, e.g. listing tags for an author, or listing authors for a tag - although this is probably something for a later version.

[ErisDS]

I've moved this comment to #6009, #6008 is also related.

[ErisDS]

I'm closing most API issues temporarily with the later label.

JSON API Overhaul & OAuth access are currently scheduled next on the roadmap