Reduce toJSON implementation: use the power of bookshelf

[kirrg001]

no issue

• simplify toJSON
• baseKey was not used - have not find a single use case
• all the functionality of our toJSON is offered in bookshelf
• omitPivot does remove pivot elements from the JSON obj (bookshelf feature)
• shallow allows you to not return relations
• make use of serialize, see http://bookshelfjs.org/docs/src_base_model.js.html#line260
• refs Bookshelf & Knex upgrade #6103

pick('shallow', 'baseKey', 'include', 'context')

We don't have to specify allowed options i think - no security risk.
But we will re-add validation, but then with the official way: use filterOptions. One of the next PR's.

---

We return all fetched relations (pre-defined with withRelated) by default.
You can disable it with shallow:true.

[ErisDS]

The toJSON implementation hasn't been updated in ages - so bookshelf has undoubtably added features to fix some of the issues we had by now.

I don't remember a lot of why things are the way they are anymore though - so I'm a little cautious over:

a) removing the pick - this is stylistic, I prefer when passing options around to use clone and or pick to avoid issues in future:

• clone for stopping pass by reference bugs
• pick means you can be sure forever exactly what properties are considered used - which is great when in 4 years you need to refactor this code again 😉
  b) why passing include is not needed anymore in certain cases? - this is probably code evolution 😁 and nothing to worry about.

Otherwise this looks 👍

[kirrg001]

a) removing the pick - this is stylistic, I prefer when passing options around to use clone and or pick to avoid issues in future:

#9425 clones the options object and makes use of permitted options (permitted options were already in place).
#9425 also adds it for toJSON (even thought it's not really required for toJSON, no security risk, because we don't request the database - but i thought consistency is good.

why passing include is not needed anymore in certain cases?

This PR only removes the use of include for the .forge function, because the fn initialize no longer remembers this.include. Why?

if (_.includes(self.include, fullKey)) {

fullKey was always the name of the relation e.g. tags
And we double checked if include contained tags - but that does not make sense, you asked for it 😁

[ErisDS]

Maybe baseKey was to do with nested relations? It might be that bookshelf or bookshelf-relations has superseded the need for this.

Things like /posts/?include=users.roles or /tags/?include=count.posts

If you're happy that all the usecases still work, then I'm happy for this to be merged!

[kirrg001]

/tags/?include=count.posts

count.posts is a virtual include and this is handled by defining a serialize fn in our include-count plugin.

/posts/?include=users.roles

The post model has no relation to users, only to author.

author.roles works though, but currently not allowed in the API layer.

The whole support of fetching nested relation is a bookshelf feature and unrelated to the our old toJSON implementation. Bookshelf-relation is not responsible for fetching data, only for updates.

---

I would merge this and see if we encounter any problems 👍