API: Apply 'pipeline' refactor to the other endpoints

[ErisDS]

In 51ac3f6 I refactored the post, user and tag endpoints to use our pipeline promise utility.

This means that serving an API request becomes a matter of taking inputs (either just options, or object & options) and passing them through a series of functions which either return a value or a promise for a value. The output form one function is passed as the argument to the next, forming a chain somewhat similar to a middleware stack.

If at any step, there is an error or promise rejection, the pipeline returns an error, meaning that validation, permission handling, and data fetching can all be steps which return their own errors and prevent the process from continuing if they go wrong.

The best thing about this approach is that it wraps individual lines of endpoint code in functions which describe what happens, like validation and handlePermissions rather than having a large block of promise code. This has reduced the codeclimate score, as the vast amounts of code duplication are now obvious, whereas before they were hidden by lines being in slightly different orders.

It would be great to continue rolling out this refactor across the other endpoints. This could be done as a single task, or as one PR per endpoint - some of them are trickier than others (and in rough order of priority):

• Posts
• Users
• Tags
• Settings
• Authentication
• Roles
• Configuration (too simple to need it)
• Themes
• Upload
• Slugs
• Notifications
• DB
• Mail

[vadimdemedes]

I'd like to pick this one up and finish the parts, that are unchecked.

I think a refactoring to pipeline utility itself would also be a bonus (as a separate PR). At the moment, it is very confusing to figure out how it works by looking at its implementation. I'd also like to write tests for the pipeline util, because grep could not find any in core/test, so I assume they don't exist.

[ErisDS]

This issue is almost done, with the exception of upload (#6648) and settings (#6028).

Upload I think is close, but the tests possibly need some work.
Settings is such a weird endpoint, it works sooo totally different to the others that it doesn't quite follow the same pattern. When #6028 was raised I self-assigned and marked it as hold because there were some changes in there that didn't quite look right.

Particularly to do with the change from settingsResult to formatResult where type seems to be missing, and handlePermissions not being split out for read and browse. Again I think the tests perhaps need some extra work to ensure the behaviour isn't changing in obscure cases.

I've tried to update, fixup & rebase #6028 but am not feeling confident with it yet. If anyone else fancies a stab grab it, else I'll try again soon.

[ErisDS]

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

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